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Preface 


The  Capability  Maturity  Model®  Integration  (CMMIsm)  project  has 
involved  a  large  number  of  people  from  different  organizations 
throughout  the  world.  These  organizations  were  using  a  CMM®  or 
multiple  CMMs  and  were  interested  in  the  benefits  of  developing  an 
integration  framework  to  aid  in  enterprise-wide  process  improvement. 

[FM101.T10 


The  CMMI  project  work  is  sponsored  by  the  U.S.  Department  of 
Defense  (DoD),  specifically  the  Office  of  the  Under  Secretary  of 
Defense,  Acquisition,  Technology,  and  Logistics  (OUSD/AT&L). 
Industry  sponsorship  is  provided  by  the  Systems  Engineering 
Committee  of  the  National  Defense  Industrial  Association  (NDIA). 

[FM101.T102] 


Organizations  from  industry,  government,  and  the  Software  Engineering 
Institute  (SEI)  joined  together  to  develop  the  CMMI  Framework,  a  set  of 
integrated  CMMI  models,  a  CMMI  appraisal  method,  and  supporting 
products.  These  organizations  donated  the  time  of  one  or  more  of  their 
people  to  participate  in  the  CMMI  project,  [fmioi.tkb] 


Development  History 


The  CMMI  project  team  has  been  working  to  provide  guidance  that 
encourages  process  improvement  in  organizations  of  any  structure. 

[FM101.HDA101.T101] 


Since  1991,  CMMs  have  been  developed  fora  myriad  of  disciplines. 
Some  of  the  most  notable  include  models  for  systems  engineering, 
software  engineering,  software  acquisition,  workforce  management  and 
development,  and  Integrated  Product  and  Process  Development. 

[FM101.HDA101  .T 1 02] 


®  CMM,  Capability  Maturity  Model,  and  Capability  Maturity  Modeling  are  registered  in  the  U.S.  Patent  and 
Trademark  Office. 

SM  CMMI  is  a  service  mark  of  Carnegie  Mellon  University. 
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Although  these  models  have  proven  useful  to  many  organizations,  the 
use  of  multiple  models  has  been  problematic.  Many  organizations 
would  like  to  focus  their  improvement  efforts  across  the  disciplines 
within  their  organizations.  However,  the  differences  among  these 
discipline-specific  models,  including  their  architecture,  content,  and 
approach,  have  limited  these  organizations’  ability  to  focus  their 
improvements  successfully.  Further,  applying  multiple  models  that  are 
not  integrated  within  and  across  an  organization  becomes  more  costly 
in  terms  of  training,  appraisals,  and  improvement  activities.  A  set  of 
integrated  models  that  successfully  addresses  multiple  disciplines  and 
has  integrated  training  and  appraisal  support  solves  these  problems. 

[FM101.HDA101.T103] 


The  CMM  lntegrationSM  project  was  formed  to  sort  out  the  problem  of 
using  multiple  CMMs.  The  CMMI  Product  Team’s  mission  was  to 
combine  three  source  models — (1)  Capability  Maturity  Model  for 
Software  (SW-CMM)  v2.0  draft  C,  (2)  Electronic  Industries  Alliance 
Interim  Standard  (EIA/IS)  731,  and  (3)  Integrated  Product  Development 
Capability  Maturity  Model  (IPD-CMM)  v0.98 — into  a  single  improvement 
framework  for  use  by  organizations  pursuing  enterprise-wide  process 
improvement,  [fmioi.hdaioi.tio6 

Developing  a  set  of  integrated  models  has  involved  more  than  simply 
adding  existing  model  materials  together.  Using  processes  that  promote 
consensus,  the  CMMI  Product  Team  has  built  a  framework  that 
accommodates  multiple  disciplines  and  is  flexible  enough  to  support 
two  different  representations  (staged  and  continuous),  [fmioi.hdaioi.tio7] 

Using  information  from  popular  and  well-regarded  models  as  source 
material,  the  CMMI  Product  Team  created  a  cohesive  set  of  integrated 
models  that  can  be  adopted  by  those  currently  using  other  CMMs,  as 
well  as  by  those  new  to  the  CMM  concept,  [fmioi.hdaioi.tio8] 

During  the  development  phase  of  the  CMMI  project,  the  team’s  mission 
included  the  development  of  a  common  framework  for  supporting  the 
future  integration  of  other  discipline-specific  CMMI  models. 

Furthermore,  the  team’s  mission  included  the  objective  of  ensuring  that 
all  of  the  products  developed  are  consistent  and  compatible  with  the 
International  Organization  for  Standardization/International 
Electrotechnical  Commission  (ISO/IEC)  15504  Technical  Report  for 
Software  Process  Assessment,  [fmioi.hdaioi.tio9] 


SM  CMM  Integration  is  a  service  mark  of  Carnegie  Mellon  University. 
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CMMI  version  0.2  was  publicly  reviewed  and  used  in  initial  pilot 
activities.  Following  release  of  that  version,  improvement  was  guided  by 
change  requests  from  the  public  review,  piloting  organizations,  and 
various  focus  group  sessions.  The  CMMI  Product  Team  evaluated  more 
than  3,000  change  requests  to  create  CMMI  version  1.0.  Shortly 
thereafter,  version  1.02  was  released,  which  incorporated  several  minor 
improvements.  As  with  any  release,  however,  the  opportunity  for  further 
improvement  remained.  Version  1.1  accommodates  further 
improvements  from  early  use  as  well  as  more  than  1 ,500  change 
requests,  [fmioi.hdaioi.tih] 
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CMMI  Product  Suite1.  Four  primary  groups  involved  in  this  development 
have  been  the  Steering  Group,  Product  Team,  Configuration  Control 
Board,  and  Stakeholders/Reviewers,  [fmioi.hdaio2.tioi 

The  Steering  Group  guides  and  approves  the  plans  of  the  Product 
Team,  provides  consultation  on  significant  CMMI  project  issues,  and 
ensures  involvement  from  a  variety  of  interested  communities. 
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Where  to  Look  for  Additional  Information 


You  can  find  additional  information,  such  as  the  intended  audience, 
background,  history  of  the  CMMI  models,  and  the  benefits  of  using  the 
CMMI  models,  in  various  other  sources.  Many  of  these  sources  are 
documented  on  the  CMMI  Web  site,  which  is  located  at 
http://www.sei.cmu.edu/cmmi/.  [fmioi.hdaio3.tioi] 


Feedback  Information 


Suggestions  for  improving  the  CMMI  Product  Suite  are  welcome.  See 
the  CMMI  Web  site  for  information  on  how  to  provide  feedback: 
http://www.sei.cmu.edu/cmmi/.  [fmioi.hdaio4.tioi] 

If  you  have  questions,  send  an  email  to  cmmi-comments@sei.cmu.edu. 

[FM1 01  .HDA1 04.T  1 03] 
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1  Introduction 


A  model  is  a  simplified  representation  of  the  world.  Capability  Maturity 
Models  (CMMs)  contain  the  essential  elements  of  effective  processes 
for  one  or  more  bodies  of  knowledge.  These  elements  are  based  on  the 
concepts  developed  by  Crosby,  Deming,  Juran,  and  Humphrey  [Crosby 
79,  Juran  88,  Deming  86,  Humphrey  89],  [FM108.T101] 

Like  other  CMMs,  Capability  Maturity  Model  Integration  (CMMI)  models 
provide  guidance  to  use  when  developing  processes.  CMMI  models  are 
not  processes  or  process  descriptions.  The  actual  processes  used  in  an 
organization  depend  on  many  factors,  including  application  domain(s) 
and  organization  structure  and  size.  In  particular,  the  process  areas  of  a 
CMMI  model  typically  do  not  map  one  to  one  with  the  processes  used  in 
your  organization,  [fmios.tkk] 


About  CMMI  Models 


A  process  is  a  leverage  point  for  an  organization’s  sustained 
improvement.  The  purpose  of  CMM  Integration  is  to  provide  guidance 
for  improving  your  organization’s  processes  and  your  ability  to  manage 
the  development,  acquisition,  and  maintenance  of  products  or  services. 
CMM  Integration  places  proven  approaches  into  a  structure  that  helps 
your  organization  appraise  its  organizational  maturity  or  process  area 
capability,  establish  priorities  for  improvement,  and  implement  these 
improvements,  [fmio8.hdaio2.tioi] 

The  CMMI  Product  Suite  contains  and  is  produced  from  a  framework 
that  provides  the  ability  to  generate  multiple  models  and  associated 
training  and  appraisal  materials.  These  models  may  reflect  content  from 
bodies  of  knowledge  (e.g.,  systems  engineering,  software  engineering, 
Integrated  Product  and  Process  Development)  in  combinations  most 
useful  to  you  (e.g.,  CMMI-SE/SW,  CMMI-SE/SW/IPPD/SS). 

[FM108.HDA102.T103] 


Your  organization  can  use  a  CMMI  model  to  help  set  process- 
improvement  objectives  and  priorities,  improve  processes,  and  provide 
guidance  for  ensuring  stable,  capable,  and  mature  processes.  A 
selected  CMMI  model  can  serve  as  a  guide  for  improvement  of 
organizational  processes,  [fmio8.hdaio2.tio2] 


Overview 
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Use  professional  judgment  to  interpret  CMMI  specific  and  generic 
practices.  Although  process  areas  depict  behavior  that  should  be 
exhibited  in  any  organization,  all  practices  must  be  interpreted  using  an 
in-depth  knowledge  of  the  CMMI  model  being  used,  the  organization, 
the  business  environment,  and  the  circumstances  involved. 

[FM108.HDA102.T104] 


Selecting  a  CMMI  Model 


There  are  multiple  CMMI  models  available,  as  generated  from  the 
CMMI  Framework.  Consequently,  you  need  to  be  prepared  to  decide 
which  CMMI  model  best  fits  your  organization’s  process-improvement 

needs.  [FM108.HDA101.T101] 

You  must  select  a  representation,  either  continuous  or  staged,  and  you 
must  determine  the  bodies  of  knowledge  you  want  to  include  in  the 
model  your  organization  will  use.  [fmio8.hdaioi.tio2] 

Representations:  Continuous  or  Staged? 

There  are  many  valid  reasons  to  select  one  representation  or  the  other. 
Perhaps  your  organization  will  choose  to  use  the  representation  it  is 
most  familiar  with.  The  following  lists  describe  some  of  the  possible 
advantages  and  disadvantages  to  selecting  each  of  the  two 
representations,  [fmio8.hdaioi.hdbioi.tioi] 

Continuous  Representation 

If  you  choose  the  continuous  representation  for  your  organization, 
expect  that  the  model  will  do  the  following:  [fmio8.hdaioi.hdbio2.tioi] 

•  Allow  you  to  select  the  order  of  improvement  that  best  meets  the 
organization’s  business  objectives  and  mitigates  the  organization’s 
areas  of  risk 

•  Enable  comparisons  across  and  among  organizations  on  a  process 
area  by  process  area  basis  or  by  comparing  results  through  the 
use  of  equivalent  staging 

•  Provide  an  easy  migration  from  Electronic  Industries  Alliance 
Interim  Standard  (EIA/IS)  731  to  CMMI 

•  Afford  an  easy  comparison  of  process  improvement  to  International 
Organization  for  Standardization  and  International  Electrotechnical 
Commission  (ISO/IEC)  15504,  because  the  organization  of  process 
areas  is  similar  to  ISO/IEC  15504 
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Staged  Representation 

If  you  choose  the  staged  representation  for  your  organization,  expect 
that  the  model  will  do  the  following:  [fmio8hdaioi.hdbio3.tioi] 

•  Provide  a  proven  sequence  of  improvements,  beginning  with  basic 
management  practices  and  progressing  through  a  predefined  and 
proven  path  of  successive  levels,  each  serving  as  a  foundation  for 
the  next 

•  Permit  comparisons  across  and  among  organizations  by  the  use  of 
maturity  levels 

•  Provide  an  easy  migration  from  the  SW-CMM  to  CMMI 

•  Provide  a  single  rating  that  summarizes  appraisal  results  and 
allows  comparisons  among  organizations 

Whether  used  for  process  improvement  or  appraisals,  both 
representations  are  designed  to  offer  essentially  equivalent  results. 

[FM108.HDA101.HDB103.T102] 

Which  Integrated  Model  to  Choose? 

Currently  there  are  four  bodies  of  knowledge  available  to  you  when 
selecting  a  CMMI  model:  [fmio8.hdaioi.hdbio4.tio6] 

•  systems  engineering 

•  software  engineering 

•  Integrated  Product  and  Process  Development 

•  supplier  sourcing 

This  text  will  refer  to  these  bodies  of  knowledge  as  “disciplines.”  For 
example,  when  we  refer  to  selecting  a  “discipline,”  it  can  be  one  of  the 
choices  listed  above.  The  CMMI  Product  Team  envisions  that  other 
bodies  of  knowledge  will  be  integrated  into  the  CMMI  Framework. 

[FM108.HDA101.HDB104.T107] 

Disciplines:  What  is  Different? 

Depending  on  the  discipline  you  select  for  your  CMMI  model,  read  the 
relevant  sections  below,  [fmio8.hdaioi.hdbio9.tioi] 

Systems  Engineering 

Systems  engineering  covers  the  development  of  total  systems,  which 
may  or  may  not  include  software.  Systems  engineers  focus  on 
transforming  customer  needs,  expectations,  and  constraints  into 
product  solutions  and  supporting  these  product  solutions  throughout  the 

life  of  the  product.  [FM108.HDA101.HDB105.T101] 
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When  you  select  systems  engineering  for  your  model,  the  model  will 
contain  the  Process  Management,  Project  Management,  Support,  and 
Engineering  process  areas.  Discipline  amplifications  specific  to  systems 
engineering  are  provided  to  help  you  interpret  specific  practices  for 
systems  engineering  where  necessary.  (See  Chapter  2  for  more 
information  about  discipline  amplifications.)  [fmio8.hdaioi  hdbio5.tio2] 

Software  Engineering 

Software  engineering  covers  the  development  of  software  systems. 
Software  engineers  focus  on  applying  systematic,  disciplined,  and 
quantifiable  approaches  to  the  development,  operation,  and 
maintenance  of  software,  [fmio8.hdaioi.hdbio6.tioi] 

When  you  select  software  engineering  for  your  model,  the  model  will 
contain  the  Process  Management,  Project  Management,  Support,  and 
Engineering  process  areas.  Discipline  amplifications  specific  to  software 
engineering  are  provided  to  help  you  interpret  specific  practices  for 
software  engineering,  [fmio8.hdaioi.hdbio6.tio2] 

Integrated  Product  and  Process  Development 

Integrated  Product  and  Process  Development  (IPPD)  is  a  systematic 
approach  that  achieves  a  timely  collaboration  of  relevant  stakeholders 
throughout  the  life  of  the  product  to  better  satisfy  customer  needs, 
expectations,  and  requirements.  The  processes  to  support  an  IPPD 
approach  are  integrated  with  the  other  processes  in  the  organization. 
The  IPPD  process  areas,  specific  goals,  and  specific  practices  alone 
cannot  achieve  IPPD.  If  a  project  or  organization  chooses  IPPD,  it 
performs  the  IPPD-specific  practices  concurrently  with  other  specific 
practices  used  to  produce  products  (e.g.,  the  Engineering  process 
areas).  That  is,  if  an  organization  or  project  wishes  to  use  IPPD,  it 
chooses  a  model  with  one  or  more  disciplines  in  addition  to  selecting 

IPPD.  [FM108.HDA101.HDB107.T101] 

When  you  select  IPPD  for  your  model,  the  model  will  contain  the 
Process  Management,  Project  Management,  Support,  and  Engineering 
process  areas  that  apply  to  both  IPPD  and  the  other  discipline(s)  you 
have  selected  for  your  model.  Discipline  amplifications  specific  to  IPPD 
are  also  provided  to  help  you  interpret  specific  practices  for  IPPD. 

[FM108.HDA101.HDB107.T102] 
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Supplier  Sourcing 

As  work  efforts  become  more  complex,  projects  may  use  suppliers  to 
perform  functions  or  add  modifications  to  products  that  are  specifically 
needed  by  the  project.  When  those  activities  are  critical,  the  project 
benefits  from  enhanced  source  analysis  and  from  monitoring  supplier 
activities  before  product  delivery.  The  supplier  sourcing  discipline 
covers  acquiring  products  from  suppliers  under  these  circumstances. 

[FM108.HDA101.HDB111.T101] 


When  you  select  the  supplier  sourcing  discipline  for  your  model,  the 
model  will  contain  the  Process  Management,  Project  Management, 
Support,  and  Engineering  process  areas  that  apply  to  both  supplier 
sourcing  and  the  other  discipline(s)  you  have  selected  for  your  model. 
The  Integrated  Supplier  Management  process  area  is  included  under 
the  Project  Management  process  area  category  and  discipline 
amplifications  specific  to  supplier  sourcing  are  present  in  other  process 
areas  to  help  you  interpret  specific  practices  for  supplier  sourcing. 

[FM108.HDA101.HDB111.T102] 

A  Recommendation 

The  CMMI  Product  Team  recommends  that  you  select  both  systems 
and  software  engineering  if  you  are  selecting  either  of  these  disciplines. 
This  recommendation  is  based  on  the  fact  that  the  only  distinction 
between  the  models  for  each  of  these  disciplines  is  the  type  of 
discipline  amplifications  included.  Otherwise,  these  models  are  exactly 

the  same.  [FM108.HDA101.HDBH0.T101] 


The  Content  of  CMMI  Models 


CMMI  models  with  a  continuous  representation  consist  of  seven 

chapters  and  six  appendices:  [fmios.hdaio3.tio2] 

•  Chapter  1 :  The  Introduction  chapter  (this  chapter)  offers  a  broad 
view  of  CMMI  models,  suggestions  on  where  to  look  for  other 
information  not  included  in  CMMI  models,  and  the  typographical 
conventions  used  throughout  CMMI  models. 

•  Chapter  2:  The  Model  Components  chapter  describes  model 
components,  including  capability  levels,  goals,  and  practices. 

•  Chapter  3:  The  Model  Terminology  chapter  describes  the  approach 
taken  to  using  terms  in  CMMI  models,  as  well  as  how  terms  were 
selected  for  and  defined  in  the  glossary. 

•  Chapter  4:  The  Capability  Levels  and  Generic  Model  Components 
chapter  describes  the  capability  levels,  generic  goals,  and  generic 
practices,  which  ensure  that  the  implementation  of  processes 
associated  with  process  areas  is  effective,  repeatable,  and  lasting. 
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•  Chapter  5:  The  Framework  Interactions  chapter  provides  insight 
into  the  meaning  of  basic  and  advanced  processes  for  Project 
Management,  Process  Management,  Support,  and  Engineering 
process  areas. 

•  Chapter  6:  The  Using  CMMI  Models  chapter  explains  the  ways  in 
which  your  organization  can  use  CMMI  models. 

•  Chapter  7:  The  Process  Areas  chapter  contains  descriptions  of  the 
required,  expected,  and  informative  components  of  the  model  you 
have  selected,  including  goals,  practices,  subpractices,  and  typical 
work  products. 

The  Appendices  are  as  follows:  [fmio8.hdaio3.tio3] 

•  Appendix  A:  The  References  appendix  contains  information  you 
can  use  to  locate  the  documented  sources,  such  as  reports, 
process-improvement  models,  industry  standards,  and  books,  that 
were  used  to  create  the  content  of  the  CMMI  models. 

•  Appendix  B:  The  Acronyms  appendix  defines  acronyms  used  in  the 
CMMI  models. 

•  Appendix  C:  The  Glossary  appendix  defines  terms  used  in  the 
CMMI  models  that  are  not  adequately  defined  in  context  or  by  the 
Webster’s  American  English  dictionary. 

•  Appendix  D:  The  Required  and  Expected  Model  Elements 
appendix  contains  the  required  and  expected  components  of  each 
of  the  process  areas.  No  informative  material  is  given  other  than 
the  process  area  purpose,  titles,  and  component  titles. 

•  Appendix  E:  The  CMMI  Project  Participants  appendix  contains  a 
list  of  participants  on  the  CMMI  Steering  Group,  Product  Team, 
Configuration  Control  Board,  and  Stakeholder/Reviewer  Team. 

•  Appendix  F:  The  Equivalent  Staging  appendix  contains  a 
description  of  how  appraisals  using  a  model  with  a  continuous 
representation  can  be  translated  into  maturity  level  ratings. 


Typographical  Conventions 


The  typographical  conventions  used  in  CMMI  models  optimize  their 
readability  and  usability.  We  present  model  components  in  formats  that 
allow  you  to  quickly  find  them  on  the  page.  The  following  sections 
provide  some  tips  for  locating  various  model  components  in  CMMI 
models,  [fmios.hdaios.tioi] 

See  Chapter  2  for  definitions  of  the  model  components  mentioned. 

[FM108.HDA105.T102] 
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Specific  and  Generic  Goals 

All  specific  and  generic  goal  titles  and  statements  appear  in  bold.  The 
goal  number  (for  example,  SG  1  for  specific  goal  1  or  GG  2  for  generic 
goal  2)  appears  to  the  left  of  the  goal  title.  (Refer  to  the  Numbering 
Scheme  section  below.)  The  goal  statement  appears  in  bold  italics 
below  the  goal  title  in  a  gray  box.  A  goal  title  is  an  abbreviated  form  of 
the  goal  statement  and  is  used  for  reference  purposes.  Goal  titles  are 
not  used  for  appraisals  or  rated  in  any  way.  Only  goal  statements  are 
designed  to  be  used  for  process-improvement  and  appraisal  purposes. 

[FM108.HDA105.HDB101.T101] 

Specific  and  Generic  Practices 

All  specific  and  generic  practice  titles  and  statements  appear  in  bold 
and  are  indented  from  the  left  margin.  The  practice  number  appears  to 
the  left  of  the  practice  title.  (Refer  to  the  Numbering  Scheme  section 
below.)  The  practice  statements  appear  in  bold  italics  within  a  gray  box 
below  the  practice  title.  The  practice  title  is  not  used  for  appraisals  or 
rated  in  any  way.  The  practice  statement  is  designed  to  be  used  for 
process-improvement  and  appraisal  purposes,  [fmio8.hdaio5.hdbio2.tioi] 

References 

All  references  to  model  components  are  identifiable  in  CMMI  models 
because  they  always  appear  in  italics  and  always  begin  with  the  phrase 

“Refer  to.  ”  [FMIO8.HDAIO5.HDBIO3.TIOI] 

Introductory  Notes,  Typical  Work  Products,  and  Subpractices 

These  headings  indicate  the  location  of  introductory  notes,  typical  work 
products,  and  subpractices  within  a  process  area,  [fmio8hdaio5.hdbio4.tioi] 

Examples 

Throughout  the  process  areas,  all  examples  appear  in  boxes  and  are 
formatted  in  a  narrower  and  smaller  font  than  most  other  model 

elements.  [FM108.HDA105.HDB109.T101] 

Generic  Practice  Elaborations 

After  the  specific  practices,  the  generic  practice  titles  and  statements 
appear  that  apply  to  the  process  area.  After  each  generic  practice 
statement,  an  elaboration  may  appear  in  plain  text  with  the  heading 
“Elaboration.”  The  elaboration  provides  information  about  how  the 
generic  practice  should  be  interpreted  for  the  process  area.  If  there  is 
no  elaboration  present,  the  application  of  the  generic  practice  is  obvious 
without  an  elaboration,  [fmios.hdaios.hdbios.tioi] 
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Discipline  Amplifications 


Model  components  that  provide  guidance  for  interpreting  model 
information  for  specific  disciplines  (e.g.,  IPPD,  systems  engineering,  or 
software  engineering)  are  called  “discipline  amplifications.”  Discipline 
amplifications  are  added  to  other  model  components  where  necessary. 
These  are  easy  to  locate  because  they  appear  on  the  right  side  of  the 
page  and  have  a  title  indicating  the  discipline  that  they  address  (for 
example,  “For  Software  Engineering”),  [fmio8hdaio5.hdbio6.tioi] 

Numbering  Scheme 

In  the  continuous  representation,  the  specific  and  generic  goals  are 
numbered  sequentially.  Each  specific  goal  has  a  number  beginning  with 
SG  (SG  1 ,  for  example).  Each  generic  goal  has  a  number  beginning 

with  GG  (GG  2,  for  example).  [FM108.HDA105.HDB107.T101] 

Each  specific  practice  begins  with  SP,  followed  by  a  number  in  the  form 
x.y-z  (SP  1 .1-1 ,  for  example).  Each  generic  practice  begins  with  GP, 
followed  by  a  number  in  the  form  x.y  (GP  1 .1 ,  for  example). 

[FM108.HDA105.HDB107.T102] 


For  specific  practices,  the  x  is  the  same  number  as  the  goal  it  maps  to. 
The  y  is  the  sequence  number  of  the  specific  practice  under  the  specific 
goal.  The  z  is  the  capability  level  of  the  specific  practice. 

[FM108.HDA105.HDB107.T103] 


An  example  of  specific  practice  numbering  is  in  the  Project  Planning 
process  area.  The  first  specific  practice  is  numbered  SP  1.1-1  and  the 

second  is  SP  1 .2-1 .  [FM108.HDA105.HDB107.T104] 

For  generic  practices,  the  x  serves  two  purposes.  First,  it  corresponds 
to  the  number  of  the  generic  goal.  Second,  it  indicates  the  capability 
level  of  the  generic  practice.  The  y  is  the  sequence  number  of  the 
generic  practice  under  the  generic  goal,  [fmio8  hdaio5.hdbio7.tio5] 

Some  specific  practices  in  the  continuous  representation  are  at  a 
capability  level  higher  than  1 .  These  specific  practices  are  called 
“advanced  practices.”  Specific  practices  at  capability  level  1  are  called 
“base  practices.”  See  Chapter  2  for  more  information  about  advanced 
practices  and  base  practices,  [fmio8  hdaios.hdbio7.tio6] 

An  advanced  practice  may  or  may  not  have  an  associated  base 

practice.  [FM108.HDA105.HDB107.T107] 
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Since  the  numbering  of  specific  practices  in  the  continuous 
representation  includes  capability  levels,  the  numbering  of  specific 
practices  is  affected  by  capability  level  information.  One  example  of 
advanced  practice  numbering  is  in  the  Requirements  Management 
process  area.  The  first  specific  practice  is  numbered  SP  1.1-1.  Since  it 
is  identified  as  being  a  capability  level  1  practice,  it  is  a  base  practice. 
The  second  specific  practice  is  numbered  SP  1.2-2.  Since  it  is  identified 
as  being  a  capability  level  2  practice,  it  is  an  advanced  practice.  This 
numbering  sequence  reflects  a  base  practice  followed  by  an  unrelated 
advanced  practice,  [fmio8.hdaio5.hdbio7.tio8] 

Sometimes  an  advanced  practice  builds  on  a  base  practice.  An 
example  is  in  the  first  two  specific  practices  of  the  Requirements 
Development  process  area.  The  sequence  number  is  the  same  for  both 
specific  practices,  that  is,  SP  1.1-1  and  SP  1.1-2.  (In  the  staged 
representation,  only  SP  1.1-2  exists,  but  it  is  numbered  as  SP  1 .1 ,  since 
capability  levels  are  not  present  in  the  staged  representation.) 

[FM108.HDA105.HDB107.T109] 


See  Chapter  2  for  a  description  of  advanced  practices  and  base 

practices.  [FM108.HDA105.HDB107.TH0] 

Paragraph  Identifier  Codes 

At  the  end  of  single  paragraphs  or  sets  of  paragraphs  throughout  the 
model,  you  will  find  unique  strings  of  characters  in  brackets  (e.g., 
[FM108.HDA105.HDB107.T1 10]).  These  strings  of  characters  are 
called  “paragraph  identifier  codes.”  These  codes  are  unique,  but  do  not 
necessarily  appear  in  any  numeric  sequence.  These  codes  do  not  hold 
any  special  meaning  for  model  users,  but  rather,  they  enable  the 
generation  of  individual  CMMI  models  from  the  CMMI  Framework 
database  and  allow  you  to  accurately  identify  specific  text  in  the  model. 

[FM108.HDA105.HDB108.T101] 
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2  Model  Components 


You  have  chosen  the  continuous  representation.  The  components  of 
both  the  staged  and  continuous  representations  are  process  areas, 
specific  goals,  specific  practices,  generic  goals,  generic  practices, 
typical  work  products,  subpractices,  notes,  discipline  amplifications, 
generic  practice  elaborations,  and  references.  [fmio3.tioi] 

The  continuous  representation  uses  six  capability  levels,  capability 
profiles,  target  staging,  and  equivalent  staging  as  organizing  principles 
for  the  model  components.  The  continuous  representation  groups 
process  areas  by  affinity  categories  and  designates  capability  levels  for 
process  improvement  within  each  process  area.  Capability  profiles 
(described  later  in  this  chapter)  represent  process-improvement  paths 
by  illustrating  improvement  evolution  for  each  of  the  process  areas. 
Equivalent  staging  is  used  to  relate  the  process  areas’  capability  levels 
to  the  staged  representation’s  maturity  levels.  [fmio3.tio3] 

Within  each  process  area,  the  specific  goals  and  specific  practices  are 
listed  first,  followed  by  the  generic  goals  and  generic  practices.  The 
continuous  representation  uses  the  generic  goals  to  organize  the 
generic  practices.  [fmio3.tios] 

In  this  chapter,  we  describe  each  component  of  the  continuous 
representation,  the  relationships  between  the  components,  and  the 
relationships  between  the  two  representations.  Many  of  the  components 
described  here  are  also  components  of  CMMI  models  with  a  staged 
representation.  [fmio3.tio7] 


Structural  Overview 


A  CMMI  model  with  a  continuous  representation  is  illustrated  in  Figure 

1.  [FM103.HDA101.T101] 
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Process  Area  1 

Process  Area  2  ] 

Process  Area  n 

yv,  * 

Figure  1:  CMMI  Model  Components  ifmio3.hdaioi.tio3] 


As  illustrated  in  Figure  1 ,  the  specific  goals  organize  specific  practices 
and  the  generic  goals  organize  generic  practices.  Each  specific  and 
generic  practice  corresponds  to  a  capability  level.  Specific  goals  and 
specific  practices  apply  to  individual  process  areas,  [fmio3.hdaioi.tio5] 

Generic  goals  and  generic  practices  apply  to  multiple  process  areas. 
The  generic  goals  and  generic  practices  define  a  sequence  of  capability 
levels  that  represent  improvements  in  the  implementation  and 
effectiveness  of  all  the  processes  you  choose  to  improve.  [fmio3.hdaioi.tio6] 

CMMI  models  are  designed  to  describe  discrete  levels  of  process 
improvement.  In  the  continuous  representation,  capability  levels  provide 
a  recommended  order  for  approaching  process  improvement  within 
each  process  area.  At  the  same  time,  the  continuous  representation 
allows  some  flexibility  for  the  order  in  which  the  process  areas  are 
addressed,  [fmio3.hdaioi.tio7] 

This  representation  focuses  on  best  practices  your  organization  can  use 
to  improve  processes  in  the  process  areas  it  has  chosen  to  address. 
Before  you  begin  using  a  CMMI  model  for  improving  processes,  you 
must  map  your  processes  to  CMMI  process  areas.  This  mapping 
enables  you  to  control  process  improvement  in  your  organization  by 
helping  you  track  your  organization’s  level  of  conformance  to  the  CMMI 
model  you  are  using.  It  is  not  intended  that  every  CMMI  process  area 
maps  one  to  one  with  your  organization’s  processes.  [fmio3.hdaioi .tiosj 
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Capability  Levels 

All  CMMI  models  with  a  continuous  representation  reflect  capability 
levels  in  their  design  and  content.  A  capability  level  consists  of  related 
specific  and  generic  practices  for  a  process  area  that  can  improve  the 
organization’s  processes  associated  with  that  process  area.  As  you 
satisfy  the  generic  and  specific  goals  for  a  process  area  at  a  particular 
capability  level,  and  you  achieve  that  capability  level,  you  reap  the 
benefits  of  process  improvement,  [fmio3.hdaioi  hdbio2.tioi] 

Capability  levels  focus  on  growing  the  organization’s  ability  to  perform, 
control,  and  improve  its  performance  in  a  process  area.  Capability 
levels  enable  you  to  track,  evaluate,  and  demonstrate  your 
organization’s  progress  as  you  improve  processes  associated  with  a 
process  area.  Capability  levels  build  on  each  other,  providing  a 
recommended  order  for  approaching  process  improvement. 

[FM103.HDA101.HDB102.T102] 


There  are  six  capability  levels,  designated  by  the  numbers  0  through  5: 

[FM103.HDA101.HDB102.T103] 

0.  Incomplete 

1 .  Performed 

2.  Managed 

3.  Defined 

4.  Quantitatively  Managed 

5.  Optimizing 

See  Chapter  4  for  a  detailed  description  of  the  capability  levels. 

[FM103.HDA101.HDB102.T104] 

Required,  Expected,  and  Informative  Components 

The  components  of  a  CMMI  model  are  grouped  into  three  categories 

that  reflect  how  they  are  to  be  interpreted:  [fmio3.hdaioi  hdbih.tioi] 

•  Required:  Specific  goals  and  generic  goals  are  required  model 
components.  These  components  must  be  achieved  by  an 
organization’s  planned  and  implemented  processes.  Required 
components  are  essential  to  rating  the  achievement  of  a  process 
area.  Goal  achievement  (or  satisfaction)  is  used  in  appraisals  as 
the  basis  upon  which  process  area  satisfaction  and  organizational 
maturity  are  determined.  Only  the  statement  of  the  specific  or 
generic  goal  is  a  required  model  component.  The  title  of  a  specific 
or  generic  goal  and  any  notes  associated  with  the  goal  are 
considered  informative  model  components. 

•  Expected:  Specific  practices  and  generic  practices  are  expected 
model  components.  Expected  components  describe  what  an 
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organization  will  typically  implement  to  achieve  a  required 
component.  Expected  components  guide  those  implementing 
improvements  or  performing  appraisals.  Either  the  practices  as 
described,  or  acceptable  alternatives  to  them,  are  expected  to  be 
present  in  the  planned  and  implemented  processes  of  the 
organization  before  goals  can  be  considered  satisfied.  Only  the 
statement  of  the  practice  is  an  expected  model  component.  The 
title  of  a  practice  and  any  notes  associated  with  the  practice  are 
considered  informative  model  components. 

•  Informative:  Subpractices,  typical  work  products,  discipline 
amplifications,  generic  practice  elaborations,  goal  and  practice 
titles,  goal  and  practice  notes,  and  references  are  informative 
model  components  that  help  model  users  understand  the  goals 
and  practices  and  how  they  can  be  achieved.  Informative 
components  provide  details  that  help  model  users  get  started  in 
thinking  about  how  to  approach  goals  and  practices. 

The  CMMI  glossary  of  terms  is  not  a  required,  expected,  or  informative 
element  of  CMMI  models.  The  terms  in  the  glossary  should  be 
interpreted  within  the  context  of  the  component  where  they  appear. 

[FM103.HDA101.HDB111.T102] 


When  you  use  a  CMMI  model  as  a  guide,  you  plan  and  implement 
processes  that  conform  to  the  required  and  expected  components  of 
process  areas.  Conformance  with  a  process  area  means  that  in  the 
planned  and  implemented  processes  there  is  an  associated  process  (or 
processes)  that  addresses  either  the  specific  and  generic  practices  of 
the  process  area  or  alternatives  that  clearly  and  unequivocally 
accomplish  a  result  that  meets  the  goal  associated  with  that  specific  or 
generic  practice,  [fmio3.hdaioi.hdbih.tio3] 


Model  Components 


Process  Areas 

A  process  area  is  a  cluster  of  related  practices  in  an  area  that,  when 
performed  collectively,  satisfy  a  set  of  goals  considered  important  for 
making  significant  improvement  in  that  area.  All  CMMI  process  areas 
are  common  to  both  continuous  and  staged  representations.  In  the 
continuous  representation,  process  areas  are  organized  by  process 
area  categories,  [fmio3.hdaio2.hdbioi.th6] 
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Specific  Goals 

Specific  goals  apply  to  a  process  area  and  address  the  unique 
characteristics  that  describe  what  must  be  implemented  to  satisfy  the 
process  area.  Specific  goals  are  required  model  components  and  are 
used  in  appraisals  to  help  determine  whether  a  process  area  is 
satisfied.  There  can  be  specific  practices  at  different  capability  levels 
mapped  to  the  same  goal.  However,  every  goal  has  at  least  one 
capability  level  1  practice  mapped  to  it.  [fmio3.hdaio2  hdbio3.tio2] 

Specific  Practices 

A  specific  practice  is  an  activity  that  is  considered  important  in 
achieving  the  associated  specific  goal.  The  specific  practices  describe 
the  activities  expected  to  result  in  achievement  of  the  specific  goals  of  a 
process  area.  Every  specific  practice  is  associated  with  a  capability 
level.  Specific  practices  are  expected  model  components. 

[FM103.HDA102.HDB104.T102] 

Base  Practices 

In  the  continuous  representation,  all  the  specific  practices  with  a 
capability  level  of  1  are  called  “base  practices.”  [fmio3.hdaio2.hdbih.tioi] 

Advanced  Practices 

In  the  continuous  representation,  all  the  specific  practices  with  a 
capability  level  of  2  or  higher  are  called  “advanced  practices.” 

[FM103.HDA102.HDB112.T101] 


For  example,  within  the  Requirements  Management  process  area, 
“Develop  an  understanding  with  the  requirements  providers  on  the 
meaning  of  the  requirements”  is  a  capability  level  1  specific  practice, 
whereas  “Obtain  commitment  to  the  requirements  from  the  project 
participants”  is  a  capability  level  2  specific  practice,  [fmio3.hdaio2.hdbh2.tio2] 

Sometimes  an  advanced  practice  builds  on  a  base  practice.  When  this 
happens,  the  advanced  practice  is  included  in  the  staged  representation 
as  a  specific  practice,  but  the  base  practice  is  not.  Rather,  the  base 
practice  is  presented  as  informative  material  after  the  specific  practice. 
This  informative  material  explains  how  the  base  and  advanced 
practices  appear  in  the  continuous  representation.  Other  times,  an 
advanced  practice  does  not  build  on  a  base  practice.  When  this 
happens,  the  advanced  practice  is  automatically  included  in  the  staged 
representation  as  a  specific  practice,  [fmio3  hdaio2.hdbh2.tio3] 
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The  specific  practice  numbering  scheme  identifies  these  conditions.  In 
the  continuous  representation,  specific  practices  are  numbered  so  that 
the  reader  can  identify  to  which  specific  goal  the  practice  is  mapped,  its 
sequence  number  and  its  capability  level.  For  example,  in  the 
Requirements  Management  case  above,  the  first  specific  practice  of  the 
first  specific  goal  will  be  numbered  1.1-1  and  the  second  will  be  1 .2-2. 

In  the  case  where  a  specific  practice  builds  on  another,  the  sequence 
number  will  be  the  same  for  both  specific  practices,  that  is,  1.1-1  and 
1.1-3.  In  the  staged  representation,  only  the  number  1.1  appears. 

[FM103.HDA102.HDB112.T104] 

Typical  Work  Products 

Typical  work  products  are  an  informative  model  component  that 
provides  example  outputs  from  a  specific  or  generic  practice.  These 
examples  are  called  “typical  work  products”  because  there  are  often 
other  work  products  that  are  just  as  effective,  but  are  not  listed. 

[FM103.HDA102.HDB113.T101] 

Subpractices 

Subpractices  are  detailed  descriptions  that  provide  guidance  for 
interpreting  specific  or  generic  practices.  Subpractices  may  be  worded 
as  if  prescriptive,  but  are  actually  an  informative  component  in  CMMI 
models  meant  only  to  provide  ideas  that  may  be  useful  for  process 
improvement,  [fmio3.hdaio2.hdbh4.tioi] 

Discipline  Amplifications 

Discipline  amplifications  are  informative  model  components  that  contain 
information  relevant  to  a  particular  discipline  and  are  associated  with 
specific  practices.  For  example,  if  in  the  CMMI-SE/SW  model,  you  want 
to  find  a  discipline  amplification  for  software  engineering,  you  would 
look  in  the  model  for  items  labeled  “For  Software  Engineering.”  The 
same  is  true  for  other  disciplines,  [fmio3.hdaio2.hdbh5.tioi] 

Generic  Goals 

Each  capability  level  (1-5)  has  only  one  generic  goal  that  describes  the 
institutionalization  that  the  organization  must  achieve  at  that  capability 
level.  Thus,  there  are  five  generic  goals;  each  appears  in  every  process 
area.  Achievement  of  a  generic  goal  in  a  process  area  signifies 
improved  control  in  planning  and  implementing  the  processes 
associated  with  that  process  area  thus  indicating  whether  these 
processes  are  likely  to  be  effective,  repeatable,  and  lasting.  Generic 
goals  are  required  model  components  and  are  used  in  appraisals  to 
determine  whether  a  process  area  is  satisfied.  (Only  the  generic  goal 
title  and  statement  appear  in  the  process  areas.)  [fmio3.hdaio2.hdbio5.tio3] 
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See  Chapter  4  for  a  detailed  description  of  the  generic  goals. 

[FM103.HDA102.HDB105.T102] 

Generic  Practices 

Generic  practices  provide  institutionalization  to  ensure  that  the 
processes  associated  with  the  process  area  will  be  effective, 
repeatable,  and  lasting.  Generic  practices  are  categorized  by  capability 
level  and  are  expected  components  in  CMMI  models.  In  the  continuous 
representation,  each  generic  practice  maps  to  one  generic  goal.  (Only 
the  generic  practice  title,  statement,  and  elaborations  appear  in  the 
process  areas.)  [fmio3.hdaio2.hdbio7.tio3] 

See  Chapter  4  for  a  detailed  description  of  the  generic  practices. 

[FM103.HDA102.HDB107.T102] 


Generic  practices  may  depend  on  certain  process  areas  in  two  different 

ways:  [FMi03.HDAi02.HDBi07.Ti04] 

•  Some  generic  practices  rely  on  the  support  of  a  process  area.  An 
example  is  the  generic  practice  “Place  designated  work  products  of 
the  process  under  appropriate  levels  of  configuration 
management.”  The  Configuration  Management  process  area 
supports  this  generic  practice.  This  means  that  to  implement  this 
generic  practice  for  another  process  area,  you  might  choose  to 
implement  the  Configuration  Management  process  area,  all  or  in 
part,  to  make  it  happen. 

•  Other  generic  practices  cannot  be  executed  without  an  output  from 
a  process  area.  An  example  is  the  generic  practice  “Establish  and 
maintain  the  description  of  a  defined  process.”  This  generic 
practice  requires  the  process  assets  created  by  the  implementation 
of  the  Organizational  Process  Definition  process  area.  This  means 
that  to  make  full  use  of  this  generic  practice  for  another  process 
area,  you  should  first  use  the  Organizational  Process  Definition 
process  area,  all  or  in  part,  to  secure  the  output  needed  to  achieve 
the  generic  practice. 

Generic  Practice  Elaborations 

Generic  practice  elaborations  are  informative  model  components  that 
appear  in  each  process  area  to  provide  guidance  on  how  the  generic 
practices  should  uniquely  be  applied  to  the  process  area.  For  example, 
when  the  generic  practice  “Train  the  people  performing  or  supporting 
the  planned  process  as  needed”  is  incorporated  into  the  Configuration 
Management  process  area,  the  specific  kinds  of  training  for  doing 
configuration  management  are  described,  [fmio3.hdaio2.hdbh6.tioi] 
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References 


References  are  informative  model  components  that  direct  the  user  to 
additional  or  more  detailed  information  in  related  process  areas.  Typical 
phrases  expressing  these  pointers  are  “Refer  to  the  Decision  Analysis 
and  Resolution  process  area  for  determining  the  best  integration 
strategy”  or  “Refer  to  the  Project  Planning  process  area  for  more 
information  about  global  project  planning.”  All  references  are  clearly 
marked  in  italics,  [fmio3.hdaio2.hdbh7.hoi] 


Model  Representation  Comparison 


The  continuous  representation  uses  capability  levels  to  measure 
process  improvement,  while  the  staged  representation  uses  maturity 
levels.  The  main  difference  between  maturity  levels  and  capability 
levels  is  the  representation  they  belong  to  and  how  they  are  applied: 

[FM103.HDA103.T101] 

•  Capability  levels,  which  belong  to  the  continuous  representation, 
apply  to  an  organization’s  process-improvement  achievement  for 
each  process  area.  There  are  six  capability  levels,  numbered  0 
through  5.  Each  capability  level  corresponds  to  a  generic  goal  and 
a  set  of  generic  and  specific  practices. 


Capability 

Level 

Continuous  Representation 
Capability  Levels 

0 

Incomplete 

1 

Performed 

2 

Managed 

3 

Defined 

4 

Quantitatively  Managed 

5 

Optimizing 

[FM103.HDA103.T102] 

•  Maturity  levels,  which  belong  to  the  staged  representation,  apply  to 
an  organization’s  overall  maturity.  There  are  five  maturity  levels, 
numbered  1  through  5.  Each  maturity  level  comprises  a  predefined 
set  of  process  areas. 
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Maturity 

Level 

Staged  Representation 
Maturity  Levels 

1 

Initial 

2 

Managed 

3 

Defined 

4 

Quantitatively  Managed 

5 

Optimizing 

[FM1 03.HDA1 03.T  1 04] 


The  continuous  representation  has  more  specific  practices  than  the 
staged  representation  because  the  continuous  representation  has  two 
types  of  specific  practices,  base  and  advanced,  whereas  the  staged 
representation  has  only  one  type  of  specific  practice,  [fmio3.hdaio3.tio5] 

In  the  continuous  representation,  generic  practices  exist  for  capability 
levels  1-5,  whereas,  in  the  staged  representation,  only  the  generic 
practices  from  capability  levels  2  and  3  appear;  there  are  no  generic 
practices  from  capability  levels  1, 4,  and  5.  [fmio3.hdaio3.tioo] 

There  is  an  additional  appendix,  Appendix  F,  in  the  continuous 
representation  that  discusses  equivalent  staging.  Equivalent  staging 
enables  the  results  of  appraisals  using  the  continuous  representation  to 
be  translated  into  maturity  levels,  [fmio3.hdaio3.tio7] 


Continuous  Representation  Results 


Capability  Level  Profiles 

In  the  continuous  representation,  a  capability  level  profile  is  a  list  of 
process  areas  and  their  corresponding  capability  levels.  This  profile  is  a 
way  for  the  organization  to  track  its  capability  level  by  process  area. 

[FM103.HDA104.HDB101.T101] 


The  profile  is  an  achievement  profile  when  it  represents  the 
organization’s  progress  for  each  process  area  while  climbing  up  the 
capability  levels.  Alternatively,  the  profile  is  a  target  profile  when  it 
represents  the  organization’s  process-improvement  objectives.  An 
achievement  profile,  when  compared  with  a  target  profile,  enables  you 
not  only  to  track  your  organization’s  process-improvement  progress,  but 
also  to  demonstrate  your  organization’s  progress  to  management. 
Maintaining  capability  level  profiles  is  advisable  when  using  a 
continuous  representation,  [fmio3.hdaio4.hdbioi.tio2] 
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Target  Staging 


Target  staging  is  a  sequence  of  target  profiles  that  describe  the  path  of 
process  improvement  to  be  followed  by  the  organization.  When  building 
target  profiles,  the  organization  should  pay  attention  to  the 
dependencies  between  generic  practices  and  process  areas.  When  a 
generic  practice  is  dependent  upon  a  certain  process  area,  either  to 
carry  out  the  generic  practice  or  to  provide  a  prerequisite  product,  the 
generic  practice  will  be  ineffective  when  the  process  area  is  not 
implemented.  When  a  target  profile  is  chosen  with  these  dependencies 
accounted  for,  the  target  profile  is  admissible,  [fmio3.hdaio4  hdbio2.tioi] 

Equivalent  Staging 

Sometimes  it  may  be  desirable  to  convert  an  achievement  profile  for  an 
organization  into  a  maturity  level.  This  conversion  is  made  possible  by 
“equivalent  staging.”  See  Appendix  F  for  more  information  about 
equivalent  staging  and  the  rules  that  make  it  possible  to  convert  a  target 
profile  or  achievement  profile  into  a  maturity  level,  [fmio3.hdaio4  hdbio3.tioi] 
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3  Model  Terminology 


In  any  CMMI  model,  the  terminology  used  and  how  it  is  defined  are 
important  to  understanding  the  content.  Although  a  model  glossary  is 
included  in  Appendix  C,  some  terms  are  used  in  a  special  way 
throughout  CMMI  models,  [fmih.tioi] 


Terminology  Evolution 


When  developing  the  CMMI  models,  the  Product  Team  started  with  the 
terminology  used  in  the  source  models.  However,  since  this  terminology 
was  not  consistent,  and  in  some  instances  terms  conflicted  with  one 
another,  the  Product  Team  had  to  decide  which  terms  should  be  used 
and  which  were  to  be  abandoned.  This  was  accomplished  throughout 
the  model  development  process  by  consensus,  [fmim.hdaioi.tioi] 

Inevitably,  consensus  was  reached  when  the  terms  selected  were 
neutral,  broad,  and  flexible.  When  conflicts  were  identified  among 
potential  user  groups  (government  and  industry)  or  disciplines  (e.g., 
software  engineering,  systems  engineering),  a  compromise  was 
reached.  The  team  chose  not  to  use  some  terms  that  were  too  closely 
identified  with  a  specific  interest  group  and  instead  favored  terms  that 
were  more  broadly  accepted,  [fmh4.hdaioi.tio2] 

Furthermore,  terms  were  chosen  to  express  concepts  consistently 
throughout  the  models.  Definitions  for  these  terms  were  communicated 
to  the  entire  Product  Team  to  encourage  consistent  usage.  Despite 
these  efforts,  some  differences  in  interpretation  are  inevitable.  You 
should  always  apply  the  guidance  herein  in  the  way  that  provides  the 
greatest  value  to  your  process-improvement  effort,  [fmh4.hdaioi.tio3] 


Common  Terminology  with  Special  Meaning 


Some  of  the  terms  used  in  CMMI  models  have  meanings  attached  to 
them  that  differ  from  their  everyday  use.  These  terms  are  not  included 
in  the  glossary,  we  have  explained  their  use  in  CMMI  models  in  this 

chapter.  [FMH4.HDA102.T101] 
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Adequate,  Appropriate,  As  Needed 

These  words  are  used  so  that  you  can  interpret  goals  and  practices  in 
light  of  your  organization’s  business  objectives.  When  using  any  CMMI 
model,  you  must  interpret  the  practices  so  that  they  work  for  your 
organization.  These  terms  are  used  in  goals  and  practices  where 
certain  activities  may  not  be  done  all  of  the  time,  [fmh4  hdaio2.hdbioi.tioi] 

Establish  and  Maintain 

When  using  a  CMMI  model,  you  will  encounter  goals  and  practices  that 
include  the  phrase  “establish  and  maintain.”  This  phrase  connotes  a 
meaning  beyond  the  component  terms;  it  includes  documentation  and 
usage.  For  example,  “Establish  and  maintain  an  organizational  policy 
for  planning  and  performing  the  organizational  process  focus  process” 
means  that  not  only  must  a  policy  be  formulated,  but  it  also  must  be 
documented  and  it  must  be  used  throughout  the  organization. 

[FM114.HDA102.HDB102.T101] 

Customer 

A  “customer”  is  the  party  (individual,  project,  or  organization) 
responsible  for  accepting  the  product  or  for  authorizing  payment.  The 
customer  is  external  to  the  project,  but  not  necessarily  external  to  the 
organization.  The  customer  may  be  a  higher  level  project.  Customers 
are  a  subset  of  stakeholders,  [fmh4.hdaio2  hdbio3.tioi] 

Stakeholder 

A  “stakeholder”  is  a  group  or  individual  that  is  affected  by  or  in  some 
way  accountable  for  the  outcome  of  an  undertaking.  Stakeholders  may 
include  project  members,  suppliers,  customers,  end  users,  and  others. 

[FM114.HDA102.HDB104.T101] 

Relevant  Stakeholder 

The  term  “relevant  stakeholder”  is  used  to  designate  a  stakeholder  that 
is  identified  for  involvement  in  specified  activities  and  is  included  in  an 
appropriate  plan.  (See  the  Plan  Stakeholder  Involvement  specific 
practice  in  the  Project  Planning  process  area  and  the  Identify  and 
Involve  Relevant  Stakeholders  generic  practice.)  [fmh4.hdaio2.hdbio5.tioi] 

Manager 

Within  the  scope  of  CMMI  models,  the  word  “manager”  refers  to  a 
person  who  provides  technical  and  administrative  direction  and  control 
to  those  performing  tasks  or  activities  within  the  manager’s  area  of 
responsibility.  The  traditional  functions  of  a  manager  include  planning, 
organizing,  directing,  and  controlling  work  within  an  area  of 
responsibility,  [fmh4.hdaio2.hdbio6.tioi] 
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Project  Manager 

In  the  CMMI  Product  Suite,  a  “project  manager”  is  the  person 
responsible  for  planning,  directing,  controlling,  structuring,  and 
motivating  the  project.  The  project  manager  is  responsible  for  satisfying 
the  customer,  [fmii4.hdaio2.hdbio7.tioi] 

Senior  Manager 

The  term  “senior  manager,”  when  used  in  a  CMMI  model,  refers  to  a 
management  role  at  a  high  enough  level  in  an  organization  that  the 
primary  focus  of  the  person  filling  the  role  is  the  long-term  vitality  of  the 
organization,  rather  than  short-term  project  and  contractual  concerns 
and  pressures.  A  senior  manager  has  authority  to  direct  the  allocation 
or  reallocation  of  resources  in  support  of  organizational  process- 
improvement  effectiveness.  [fmii4.hdaio2.hdbios.tioi] 

A  senior  manager  can  be  any  manager  who  satisfies  this  description, 
including  the  head  of  the  organization.  Synonyms  for  “senior  manager” 
include  “executive”  and  “top-level  manager.”  However,  these  synonyms 
are  not  used  in  CMMI  models  to  ensure  consistency  and  usability. 

[FM114.HDA102.HDB108.T102] 

Shared  Vision 

In  the  CMMI  Product  Suite,  a  “shared  vision”  is  a  common 
understanding  of  guiding  principles  including  mission,  objectives, 
expected  behavior,  values,  and  final  outcomes,  which  are  developed 
and  used  by  a  group,  such  as  an  organization,  project,  or  team. 

Creating  a  shared  vision  requires  that  all  people  in  the  group  have  an 
opportunity  to  speak  and  be  heard  about  what  really  matters  to  them. 

[FM114.HDA102.HDB109.T101] 

Organization 

An  organization  is  typically  an  administrative  structure  in  which  people 
collectively  manage  one  or  more  projects  as  a  whole,  and  whose 
projects  share  a  senior  manager  and  operate  under  the  same  policies. 
However,  the  word  “organization”  as  used  throughout  CMMI  models 
can  apply  to  one  person  who  performs  a  function  in  a  small  organization 
that  might  be  performed  by  a  group  of  people  in  a  large  organization. 
See  the  definition  of  “organizational  unit”  in  Appendix  C,  the  glossary. 

[FM114.HDA102.HDB110.T101] 
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Enterprise 

When  CMMI  models  refer  to  an  “enterprise,”  they  illustrate  the  larger 
entity  not  always  reached  by  the  word  “organization.”  Companies  may 
consist  of  many  organizations  in  many  different  locations  with  different 
customers.  The  word  “enterprise”  refers  to  the  full  composition  of 
companies,  [fmii4.hdaio2.hdbiii.tioi] 

Development 

The  word  “development,”  when  used  in  the  CMMI  Product  Suite,  implies 
not  only  development  activities,  but  also  maintenance  activities. 

Projects  that  benefit  from  the  best  practices  of  CMMI  can  focus  on 
maintenance,  development,  or  both,  [fmh4.hdaio2.hdbh2.tioi] 

Discipline 

The  word  “discipline,”  when  used  in  the  CMMI  Product  Suite,  refers  to 
the  bodies  of  knowledge  available  to  you  when  selecting  a  CMMI  model 
(e.g.,  systems  engineering).  The  CMMI  Product  Team  envisions  that 
other  bodies  of  knowledge  will  be  integrated  into  the  CMMI  Framework. 

[FM114.HDA102.HDB113.T101] 

Project 

In  CMMI  models,  a  “project”  is  a  managed  set  of  interrelated  resources 
that  delivers  one  or  more  products  to  a  customer  or  end  user.  This  set 
of  resources  has  a  definite  beginning  and  end  and  typically  operates 
according  to  a  plan.  Such  a  plan  is  frequently  documented  and  specifies 
the  product  to  be  delivered  or  implemented,  the  resources  and  funds 
used,  the  work  to  be  done,  and  a  schedule  for  doing  the  work.  A  project 
can  be  composed  of  projects,  [fmh4.hdaio2.hdbh4.tioi] 

Product 

The  word  “product”  is  used  throughout  the  CMMI  Product  Suite  to  mean 
any  tangible  output  or  service  that  is  a  result  of  a  process  and  that  is 
intended  for  delivery  to  a  customer  or  end  user.  A  product  is  a  work 
product  that  is  delivered  to  the  customer,  [fmh4.hdaio2  hdbh5.tioi] 

Work  Product 

The  term  “work  product”  is  used  throughout  the  CMMI  Product  Suite  to 
mean  any  artifact  produced  by  a  process.  These  artifacts  can  include 
files,  documents,  parts  of  the  product,  services,  processes, 
specifications,  and  invoices.  Examples  of  processes  to  be  considered 
as  work  products  include  a  manufacturing  process,  a  training  process, 
and  a  disposal  process  for  the  product.  A  key  distinction  between  a 
work  product  and  a  product  component  is  that  a  work  product  need  not 
be  engineered  or  part  of  the  end  product,  [fmh4.hdaio2  hdbh6.tioi] 
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In  various  places  in  CMMI  models,  you  will  see  the  phrase  “work 
products  and  services.”  Even  though  the  definition  of  work  product 
includes  services,  this  phrase  is  used  to  emphasize  the  inclusion  of 
services  in  the  discussion,  [fmh4.hdaio2hdbh6.tio2] 

Product  Component 

The  term  “product  component”  is  used  as  a  relative  term  in  CMMI 
models.  In  CMMI,  product  components  are  lower  level  components  of 
the  product;  product  components  are  integrated  to  “build”  the  product. 
There  may  be  multiple  levels  of  product  components.  A  product 
component  is  any  work  product  that  must  be  engineered  (requirements 
defined  and  designs  developed  and  implemented)  to  achieve  the 
intended  use  of  the  product  throughout  its  life,  [fmh4  hdaio2.hdbh7.tioi] 

Product  components  are  parts  of  the  product  delivered  to  the  customer 
and  may  serve  in  the  manufacture  or  use  of  the  product.  A  car  engine 
and  a  piston  are  examples  of  product  components  of  a  car  (the 
product).  The  manufacturing  process  to  machine  the  piston,  if  delivered 
to  the  customer,  is  a  product  component.  However,  if  the  manufacturing 
process  is  used  to  machine  the  piston  delivered  to  the  customer,  the 
manufacturing  process  is  a  work  product,  not  a  product  component.  The 
repair  process  used  to  remove  the  engine  from  the  car  for  repair  and 
the  process  used  to  train  the  mechanic  to  repair  the  engine  are  typically 
examples  of  product  components  because  they  are  delivered  to  the 

customer.  [FMH4.HDA102.HDBH7.T102] 

Appraisal 

In  the  CMMI  Product  Suite,  an  “appraisal”  is  an  examination  of  one  or 
more  processes  by  a  trained  team  of  professionals  using  an  appraisal 
reference  model  as  the  basis  for  determining  strengths  and 
weaknesses,  [fmh4.hdaio2.hdbh8.tioi] 

Assessment 

In  the  CMMI  Product  Suite,  an  “assessment”  is  an  appraisal  that  an 
organization  does  to  and  for  itself  for  the  purposes  of  process 
improvement.  The  word  “assessment”  is  also  used  in  the  CMMI  Product 
Suite  in  an  everyday  English  sense  (e.g.,  risk  assessment). 

[FM114.HDA102.HDB119.T101] 

Tailoring  Guidelines 

Tailoring  a  process  makes,  alters,  or  adapts  the  process  description  for 
a  particular  end.  For  example,  a  project  establishes  its  defined  process 
by  tailoring  from  the  organization’s  set  of  standard  processes  to  meet 
the  objectives,  constraints,  and  environment  of  the  project. 

[FM114.HDA102.HDB120.T101] 
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“Tailoring  guidelines”  are  used  in  CMMI  models  to  enable  organizations 
to  implement  standard  processes  appropriately  in  their  projects.  The 
organization’s  set  of  standard  processes  is  described  at  a  general  level 
that  may  not  be  directly  usable  to  perform  a  process,  [fmh4  hdaio2.hdbi2o.tio2] 

Tailoring  guidelines  aid  those  who  establish  the  defined  processes  for 
projects.  Tailoring  guidelines  cover  (1)  selecting  a  standard  process,  (2) 
selecting  an  approved  life-cycle  model,  and  (3)  tailoring  the  selected 
standard  process  and  life-cycle  model  to  fit  project  needs.  Tailoring 
guidelines  describe  what  can  and  cannot  be  modified  and  identify 
process  components  that  are  candidates  for  modification. 

[FM114.HDA102.HDB120.T103] 

Verification 

Although  “verification”  and  “validation”  at  first  seem  quite  similar  in 
CMMI  models,  on  closer  inspection  you  can  see  that  each  addresses 
different  issues.  Verification  confirms  that  work  products  properly  reflect 
the  requirements  specified  for  them.  In  other  words,  verification  ensures 
that  “you  built  it  right.”  [fmh4.hdaio2.hdbi2i.tioi] 

Validation 

Validation  confirms  that  the  product,  as  provided,  will  fulfill  its  intended 
use.  In  other  words,  validation  ensures  that  “you  built  the  right  thing.” 

[FM114.HDA102.HDB122.T101] 

Goal 

A  “goal”  is  a  required  CMMI  component  that  can  be  either  a  generic 
goal  or  a  specific  goal.  When  you  see  the  word  “goal”  in  a  CMMI  model, 
it  always  refers  to  model  components  (for  example,  generic  goal, 
specific  goal).  (In  Chapter  2,  see  the  definitions  of  “specific  goal”  and 
“generic  goal”  and  descriptions  of  how  these  terms  are  used  in  the 

CMMI  Product  Suite.)  [FM114.HDA102.HDB123.T101] 

Objective 

When  used  as  a  noun  in  the  CMMI  Product  Suite,  the  term  “objective” 
replaces  the  word  “goal”  as  used  in  its  common  everyday  sense,  since 
the  word  “goal”  is  reserved  for  use  when  referring  to  the  CMMI  model 
components  called  “specific  goals”  and  “generic  goals.” 

[FM1 14.HDA102.HDB124.T101] 
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Quality  and  Process-Performance  Objectives 

The  phrase  “quality  and  process-performance  objectives”  covers 
objectives  and  requirements  for  product  quality,  service  quality,  and 
process  performance.  Process  performance  objectives  include  product 
quality;  however,  to  emphasize  the  importance  of  product  quality,  the 
phrase  “quality  and  process-performance  objectives”  is  used  in  the 
CMMI  Product  Suite  rather  than  just  “process  performance  objectives.” 

[FM114.HDA102.HDB125.T101] 

Standard 

When  you  see  the  word  “standard”  used  as  a  noun  in  a  CMMI  model,  it 
refers  to  the  formal  mandatory  requirements  developed  and  used  to 
prescribe  consistent  approaches  to  development  (for  example,  ISO 
standards,  IEEE  standards,  organizational  standards).  Instead  of  using 
“standard”  in  its  common  everyday  sense,  we  chose  another  term  that 
means  the  same  thing  (for  example,  typical,  traditional,  usual, 
customary),  [fmii4.hdaio2.hdbi26.tioi] 


CMMI-Specific  Terminology 


The  following  terms  were  created  for  CMMI  products  or  are  critical  to 
the  understanding  of  CMMI  products,  [fmh4.hdaio3.tioi] 

CMMI  Product  Suite 

The  “CMMI  Product  Suite”  is  the  complete  set  of  products  developed 
around  the  CMMI  concept.  These  products  include  the  framework  itself, 
models,  appraisal  methods,  appraisal  materials,  and  various  types  of 
training  that  are  produced  from  the  CMMI  Framework. 

[FM114.HDA103.HDB101.T101] 

CMMI  Framework 

The  “CMMI  Framework”  is  the  basic  structure  that  organizes  CMMI 
components,  including  common  elements  of  the  current  CMMI  models 
as  well  as  rules  and  methods  for  generating  models,  their  appraisal 
methods  (including  associated  artifacts),  and  their  training  materials. 
The  framework  enables  new  disciplines  to  be  added  to  CMMI  so  that 
the  new  disciplines  will  integrate  with  the  existing  ones. 

[FM114.HDA103.HDB102.T101] 
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CMMI  Model 


Since  the  CMMI  Framework  can  generate  different  models  based  on 
the  needs  of  the  organization  using  it,  there  are  multiple  CMMI  models. 
Consequently,  the  phrase  “CMMI  model”  could  be  any  one  of  many 
collections  of  information.  The  phrase  “CMMI  models”  refers  to  one, 
some,  or  the  entire  collection  of  possible  models  that  can  be  generated 
from  the  CMMI  Framework,  [fmh4.hdaio3.hdbio3.hoi] 

Peer  Review 

The  term  “peer  review”  is  used  in  the  CMMI  Product  Suite  instead  of  the 
term  “work  product  inspection.”  Essentially,  these  terms  mean  the  same 
thing.  A  peer  review  is  the  review  of  work  products  performed  by  peers 
during  development  of  the  work  products  to  identify  defects  for  removal. 

[FM114.HDA103.HDB104.T101] 

Organization’s  Set  of  Standard  Processes 

An  “organization’s  set  of  standard  processes”  contains  the  definitions  of 
the  processes  that  guide  all  activities  in  an  organization.  These  process 
descriptions  cover  the  fundamental  process  elements  (and  their 
relationships  to  each  other)  that  must  be  incorporated  into  the  defined 
processes  that  are  implemented  in  projects  across  the  organization.  A 
standard  process  enables  consistent  development  and  maintenance 
activities  across  the  organization  and  is  essential  for  long-term  stability 
and  improvement,  [fmh4.hdaio3.hdbio5.tioi] 

The  organization’s  set  of  standard  processes  describes  the 
fundamental  process  elements  that  will  be  part  of  the  projects’  defined 
processes.  It  also  describes  the  relationships  (for  example,  ordering 
and  interfaces)  between  these  process  elements,  [fmh4.hdaio3  hdbio5.tio2] 

Process 

A  “process,”  as  used  in  the  CMMI  Product  Suite,  consists  of  activities 
that  can  be  recognized  as  implementations  of  practices  in  a  CMMI 
model.  These  activities  can  be  mapped  to  one  or  more  practices  in 
CMMI  process  areas  to  allow  a  model  to  be  useful  for  process 
improvement  and  process  appraisal.  (In  Chapter  2,  see  the  definition  of 
“process  area”  and  a  description  of  how  this  term  is  used  in  the  CMMI 

Product  Suite.)  [FMH4.HDA103.HDB106.T101] 

Managed  Process 

A  “managed  process”  is  a  performed  process  that  is  planned  and 
executed  in  accordance  with  policy;  employs  skilled  people  having 
adequate  resources  to  produce  controlled  outputs;  involves  relevant 
stakeholders;  is  monitored,  controlled,  and  reviewed;  and  is  evaluated 
for  adherence  to  its  process  description,  [fmh4  hdaio3.hdbio7.tioi] 
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Defined  Process 

A  “defined  process”  is  a  managed  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes  according  to  the  organization’s 
tailoring  guidelines;  has  a  maintained  process  description;  and 
contributes  work  products,  measures,  and  other  process-improvement 
information  to  the  organizational  process  assets.  (In  Chapters  2  and  4, 
see  the  descriptions  of  how  “defined  process”  is  used  in  the  CMMI 

Product  Suite.)  [FMH4.HDA103.HDB108.T101] 

A  project’s  defined  process  provides  a  basis  for  planning,  performing, 
and  improving  the  project’s  tasks  and  activities.  A  project  may  have 
more  than  one  defined  process  (for  example,  one  for  developing  the 
product  and  another  for  testing  the  product),  [fmh4  hdaio3.hdbio8.tio2] 

Organizational  Process  Assets 

“Organizational  process  assets”  are  artifacts  that  relate  to  describing, 
implementing,  and  improving  processes  (e.g.,  policies,  measurements, 
process  descriptions,  and  process  implementation  support  tools).  The 
term  “process  assets”  is  used  to  indicate  that  these  artifacts  are 
developed  or  acquired  to  meet  the  business  objectives  of  the 
organization,  and  they  represent  investments  by  the  organization  that 
are  expected  to  provide  current  and  future  business  value. 

[FM1 14.HDA103.HDB109.T101] 


The  organizational  process  assets  that  are  described  in  CMMI  models 
include  the  following:  [fmh4.hdaio3.hdbio9.tio2] 

•  Organization’s  set  of  standard  processes,  including  the  process 
architectures  and  process  elements 

•  Descriptions  of  life-cycle  models  approved  for  use 

•  Guidelines  and  criteria  for  tailoring  the  organization’s  set  of 
standard  processes 

•  Organization’s  measurement  repository 

•  Organization’s  process  asset  library 

In  addition,  some  process  areas  mention  two  additional  organizational 
process  assets:  the  organization’s  process  performance  baselines  and 
the  organization’s  process  performance  models,  [fmh4  hdaio3.hdbio9.tio3] 

Process  Architectures 

“Process  architecture”  describes  the  ordering,  interfaces, 
interdependencies,  and  other  relationships  among  the  process 
elements  in  a  standard  process.  Process  architecture  also  describes 
the  interfaces,  interdependencies,  and  other  relationships  between 
process  elements  and  external  processes  (for  example,  contract 
management),  [fmh4.hdaio3.hdbho.tioi] 
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Product  Life  Cycle 

A  “product  life  cycle”  is  the  period  of  time,  consisting  of  phases,  that 
begins  when  a  product  is  conceived  and  ends  when  the  product  is  no 
longer  available  for  use.  Since  an  organization  may  be  producing 
multiple  products  for  multiple  customers,  one  description  of  a  product 
life  cycle  may  not  be  adequate.  Therefore,  the  organization  may  define 
a  set  of  approved  product  life-cycle  models.  These  models  are  typically 
found  in  published  literature  and  are  likely  to  be  tailored  for  use  in  an 
organization,  [fmh4.hdaio3.hdbih.tioi] 

A  product  life  cycle  could  consist  of  the  following  phases:  (1) 
concept/vision,  (2)  feasibility,  (3)  design/development,  (4)  production, 
and  (5)  phase  out.  [fmh4.hdaio3.hdbhi.tio2] 

Organization’s  Measurement  Repository 

The  “organization’s  measurement  repository”  is  a  repository  used  to 
collect  and  make  available  measurement  data  on  processes  and  work 
products,  particularly  as  they  relate  to  the  organization’s  set  of  standard 
processes.  This  repository  contains  or  references  actual  measurement 
data  and  related  information  needed  to  understand  and  analyze  the 
measurement  data,  [fmh4.hdaio3.hdbh2.tioi] 

Examples  of  process  and  work  product  data  include  estimated  size  of 
work  products,  effort  estimates,  and  cost  estimates;  actual  size  of  work 
products,  actual  effort  expended,  and  actual  costs;  peer  review 
efficiency  and  coverage  statistics;  and  the  number  and  severity  of 

defects.  [FMH4.HDA103.HDBH2.T102] 

Organization’s  Process  Asset  Library 

The  “organization’s  process  asset  library”  is  a  library  of  information 
used  to  store  and  make  available  process  assets  that  are  potentially 
useful  to  those  who  are  defining,  implementing,  and  managing 
processes  in  the  organization.  This  library  contains  process  assets  such 
as  documents,  document  fragments,  process  implementation  aids,  and 
other  artifacts,  [fmh4.hdaio3.hdbh3.tioi] 

Examples  of  process-related  documentation  include  policies,  defined 
processes,  checklists,  lessons-learned  documents,  templates, 
standards,  procedures,  plans,  and  training  materials.  This  library  is  an 
important  resource  that  can  help  reduce  the  effort  in  using  processes. 

[FM1 14.HDA103.HDB113.T102] 
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Document 

A  “document”  is  a  collection  of  data,  regardless  of  the  medium  on  which 
it  is  recorded,  that  generally  has  permanence  and  can  be  read  by 
humans  or  machines.  So,  documents  include  both  paper  and  electronic 

documents.  [FMH4.HDA103.HDBH4.T101] 
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4  Capability  Levels  and  Generic  Model 
Components 


Overview 


The  capability  levels  and  generic  model  components  focus  on  building 
the  organization’s  ability  to  pursue  process  improvement  in  multiple 
process  areas.  Using  capability  levels,  generic  goals,  and  generic 
practices,  users  are  able  to  improve  their  processes,  as  well  as 
demonstrate  and  evaluate  their  organization’s  progress  as  they 
improve,  [fmi2i.hdaioi.tioi] 


Capability  levels  in  the  continuous  representation  provide  a 
recommended  order  for  approaching  process  improvement  within  each 
process  area,  [fmi2i.hdaioi.tio2] 


All  continuous  representations  of  CMMI  models  reflect  capability  levels 
in  their  design  and  content.  For  each  process  area,  a  capability  level 
consists  of  related  specific  and  generic  practices  that,  when  performed, 
achieve  a  set  of  goals  that  lead  to  improved  process  performance. 

[FM121.HDA101.T103] 


In  this  section,  the  phrase  “the  process”  means  the  process  or 
processes  that  implement  the  process  area.  In  Chapter  7,  the  section  of 
each  process  area  containing  generic  goals,  generic  practices,  and 
generic  practice  elaborations,  this  phrase  has  the  same  meaning. 

[FM121.HDA101.T104] 


“Institutionalization”  is  an  important  dimension  to  each  of  the  capability 
levels.  When  mentioned  below  in  the  capability  level  descriptions, 
institutionalization  implies  that  the  process  is  ingrained  in  the  way  the 
work  is  performed,  [fmi2i.hdaioi.tio5] 
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Interpreting  Specific  Goals  in  the  Continuous  Representation 


The  specific  practices  belonging  to  the  process  areas  in  the  Process 
Management,  Project  Management,  and  Support  categories  are  all 
capability  level  1  practices.  However,  other  process  areas  (e.g., 
Engineering  process  areas)  have  two  types  of  specific  practices:  base 
practices  (those  at  capability  level  1)  and  advanced  practices  (those  at 
higher  capability  levels).  For  those  process  areas  that  have  advanced 
practices,  the  wording  of  the  specific  goals  does  not  change  with 
different  capability  levels,  but  the  set  of  specific  practices  that  map  to 
them  may  change,  [fmi2i.hdaio3.tio3] 

When  using  the  continuous  representation  in  an  appraisal,  process 
areas  are  rated  relative  to  a  particular  capability  level.  There  are  six 
capability  levels  numbered  0  through  5.  In  process  areas  that  have 
advanced  practices,  the  particular  capability  level  being  considered 
determines  the  set  of  specific  practices  that  are  investigated  when 
rating  a  specific  goal.  The  rule  is  this:  when  rating  a  specific  goal 
relative  to  capability  level  N,  all  specific  practices  through  capability 
level  N  associated  with  that  specific  goal  must  be  investigated. 

[FM121.HDA103.T101] 


In  the  descriptions  of  the  capability  levels,  generic  goals,  and  generic 
practices  in  this  chapter,  the  phrase  “satisfies  ...  the  specific  goals  of 
the  process  area”  should  be  interpreted  in  light  of  this  rule. 

[FM121.HDA103.T102] 


Achieving  Capability  Levels 


Like  any  process  area,  the  capability  levels  of  process  areas  are 
achieved  through  the  application  of  generic  practices  or  suitable 
alternatives.  There  are  a  couple  of  ways  in  which  their  application  may 
not  be  immediately  obvious:  [fmi2i.hdaio4.tioi] 

•  Applying  capability  level  1  and  2  generic  practices 

•  Applying  capability  level  3,  4,  and  5  generic  practices 

Reaching  capability  level  1  for  a  process  area  is  equivalent  to  saying 
you  perform  the  process  area,  or  more  precisely,  you  are  achieving  the 
specific  goals  of  the  process  area,  [fmi2i.hdaio4.tio2] 
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Reaching  capability  level  2  for  a  process  area  is  like  saying  you 
manage  your  performance  of  the  process  area.  There  is  a  policy  that 
indicates  you  will  perform  it  (that  is,  a  process  or  processes  that  are 
intended  to  cover  it).  There  is  a  plan  for  performing  it,  there  are 
resources  provided,  responsibilities  assigned,  training  on  how  to 
perform  it,  selected  work  products  from  performing  the  process  area  are 
controlled,  etc.  What  this  means  in  detail  is  spelled  out  in  the  generic 
practice  elaborations  for  the  capability  level  2  generic  practices  that 
appear  in  the  process  area.  In  other  words,  an  organizational  activity 
can  be  planned  and  monitored  just  like  any  project  or  support  activity. 

[FM121.HDA104.T103] 


Reaching  capability  level  3  for  a  process  area  assumes  that  there  is  an 
organizational  standard  process  or  processes  that  cover  that  process 
area  that  can  be  tailored  to  the  specific  need.  There  are  two  points  to 
remember:  [fmi2i.hdaio4.tio4] 

•  Tailoring  may  result  in  making  no  changes  to  the  standard  process. 
In  other  words,  the  defined  process  and  standard  process  may  be 
identical.  Using  the  standard  process  “as  is”  is  tailoring  because 
the  choice  is  made  that  no  further  modification  is  required. 

•  Each  process  area  covers  multiple  activities,  some  of  which  are 
repeatedly  performed.  You  may  need  to  tailor  how  one  of  these 
activities  is  performed  to  account  for  new  capabilities  or 
circumstances.  For  example,  you  may  have  a  standard  for 
developing  or  obtaining  organizational  training  that  does  not 
consider  training  over  the  Web.  When  preparing  to  develop  or 
obtain  a  course  that  will  be  delivered  over  the  Web,  you  may  need 
to  tailor  that  standard  process  to  account  for  the  particular 
challenges  and  benefits  of  training  delivered  over  the  Web. 

Reaching  capability  level  4  or  5  for  a  process  area  is  conceptually 
feasible  but  may  not  be  economical  except,  perhaps,  in  situations 
where  the  product  domain  has  become  very  stable  for  an  extended 
period  of  time,  [fmi2i.hdaio4.tios] 


Capability  Level  0:  Incomplete 


An  incomplete  process  is  a  process  that  is  either  not  performed  or 
partially  performed.  One  or  more  of  the  specific  goals  of  the  process 
area  are  not  satisfied,  [clioii 


Capability  Level  1:  Performed 


A  capability  level  1  process  is  characterized  as  a  “performed  process.” 

[CL102] 
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A  performed  process  is  a  process  that  satisfies  the  specific  goals  of  the 
process  area.  It  supports  and  enables  the  work  needed  to  produce 
identified  output  work  products  using  identified  input  work  products. 

[CL102.N104] 


A  critical  distinction  between  an  incomplete  process  and  a  performed 
process  is  that  a  performed  process  satisfies  all  of  the  specific  goals  of 
the  process  area.  [CL102.N103] 


Level  1  Generic  Goals 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products.  [clio2.glioi] 


Level  1  Generic  Practices 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  process  area  to  develop  work 
products  and  provide  services  to  achieve  the  specific  goals  of  the 
process  area. 


The  purpose  of  this  generic  practice  is  to  produce  the  work  products 
and  deliver  the  services  that  are  expected  by  performing  the  process. 
These  practices  may  be  done  informally,  without  following  a 
documented  process  description  or  plan.  The  rigor  with  which  these 
practices  are  performed  depends  on  the  individuals  managing  and 
performing  the  work  and  may  vary  considerably.  [gpio2] 

When  using  the  continuous  representation  of  CMMI,  the  base  practices 
of  a  process  area  refer  to  all  of  the  capability  level  1  specific  practices 
for  the  process  area.  [gpio2.nioii 


Capability  Level  2:  Managed 


A  capability  level  2  process  is  characterized  as  a  “managed  process.” 

[CL103] 
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A  managed  process  is  a  performed  (capability  level  1)  process  that  is 
also  planned  and  executed  in  accordance  with  policy,  employs  skilled 
people  having  adequate  resources  to  produce  controlled  outputs, 
involves  relevant  stakeholders;  is  monitored,  controlled,  and  reviewed; 
and  is  evaluated  for  adherence  to  its  process  description.  The  process 
may  be  instantiated  by  an  individual  project,  group,  or  organizational 
function.  Management  of  the  process  is  concerned  with  the 
institutionalization  of  the  process  area  and  the  achievement  of  other 
specific  objectives  established  for  the  process,  such  as  cost,  schedule, 
and  quality  objectives.  See  Chapter  3  for  an  explanation  of  how 
“managed  process”  is  used  in  the  CMMI  Product  Suite.  [clio3.nio9] 

A  critical  distinction  between  a  performed  process  and  a  managed 
process  is  the  extent  to  which  the  process  is  managed.  A  managed 
process  is  planned  (the  plan  may  be  part  of  a  more  encompassing  plan) 
and  the  performance  of  the  process  is  managed  against  the  plan. 
Corrective  actions  are  taken  when  the  actual  results  and  performance 
deviate  significantly  from  the  plan.  A  managed  process  achieves  the 
objectives  of  the  plan  and  is  institutionalized  for  consistent  performance 
(see  generic  practices  below).  [cho3.nio7] 

The  objectives  for  the  process  are  determined  based  on  an 
understanding  of  the  project’s  or  organization’s  particular  needs. 
Objectives  may  be  quantitative  or  qualitative.  [clio3.nio2] 

The  objectives  for  the  process  may  be  specific  objectives  for  the 
individual  process  or  they  may  be  defined  for  a  broader  scope  (i.e.,  for  a 
set  of  processes),  with  the  individual  processes  contributing  to 
achieving  these  objectives.  These  objectives  may  be  revised  as  part  of 
the  corrective  actions  taken  for  the  process.  [clio3.nio3] 

The  control  provided  by  a  managed  process  helps  ensure  that  the 
established  process  is  retained  during  times  of  stress.  [clio3.nio4] 

The  requirements  and  objectives  for  the  process  are  established.  The 
status  of  the  work  products  and  delivery  of  the  services  are  visible  to 
management  at  defined  points  (e.g.,  at  major  milestones  and 
completion  of  major  tasks).  Commitments  are  established  among  those 
performing  the  work  and  relevant  stakeholders.  Commitments  are 
revised  as  necessary.  Work  products  are  reviewed  with  relevant 
stakeholders  and  are  controlled.  The  work  products  and  services  satisfy 
their  specified  requirements.  [clio3.nios] 

A  managed  process  is  institutionalized  by  doing  the  following:  [clio3.nio6] 

•  Adhering  to  organizational  policies 

•  Following  established  plans  and  process  descriptions 

•  Providing  adequate  resources  (including  funding,  people,  and 
tools) 
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•  Assigning  responsibility  and  authority  for  performing  the  process 

•  Training  the  people  performing  and  supporting  the  process 

•  Placing  designated  work  products  under  appropriate  levels  of 
configuration  management 

•  Identifying  and  involving  relevant  stakeholders 

•  Monitoring  and  controlling  the  performance  of  the  process  against 
the  plans  for  performing  the  process  and  taking  corrective  actions 

•  Objectively  evaluating  the  process,  its  work  products,  and  its 
services  for  adherence  to  the  process  descriptions,  standards,  and 
procedures,  and  addressing  noncompliance 

•  Reviewing  the  activities,  status,  and  results  of  the  process  with 
higher  level  management,  and  taking  corrective  action 

Institutionalization  also  implies  that  the  breadth  and  depth  of  the 

implementation  of  the  process  and  the  length  of  time  the  process  has 

been  in  place  are  appropriate  to  ensure  that  the  process  is  ingrained  in 

the  way  the  work  is  performed,  [clio3.nio8] 


Level  2  Generic  Goals 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process.  [clio3.glioi] 


Level  2  Generic  Practices 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process. 


The  purpose  of  this  generic  practice  is  to  define  the  organizational 
expectations  for  the  process  and  make  these  expectations  visible  to 
those  in  the  organization  who  are  affected.  In  general,  senior 
management  is  responsible  for  establishing  and  communicating  guiding 
principles,  direction,  and  expectations  for  the  organization.  [gpio3] 

Not  all  direction  from  senior  management  will  bear  the  label  “policy.” 
The  existence  of  appropriate  organizational  direction  is  the  expectation 
of  this  generic  practice,  regardless  of  what  it  is  called  or  how  it  is 
imparted.  [gpio3.nioi] 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process. 


The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to 
perform  the  process  and  achieve  the  established  objectives,  to  prepare 
a  plan  for  performing  the  process,  to  prepare  a  process  description,  and 
to  get  agreement  on  the  plan  from  relevant  stakeholders.  [gpio4] 

Requirements  for  the  process's  specified  work  products  and  for 
performing  the  work  may  be  derived  from  other  requirements.  In  the 
case  of  a  project’s  processes,  they  may  come  from  that  project’s 
requirements  management  process;  in  the  case  of  an  organization’s 
process,  they  may  come  from  organizational  sources.  [gpio4  nioij 

The  objectives  for  the  process  may  be  derived  from  other  plans  (e.g., 
the  project  plans).  Included  are  objectives  for  the  specific  situation, 
including  quality,  cost,  and  schedule  objectives.  For  example,  an 
objective  might  be  to  reduce  the  cost  of  performing  a  process  for  this 
implementation  over  the  previous  implementation.  [gpio4.nio2] 

Although  a  generic  practice,  by  definition,  applies  to  all  process  areas, 
the  practical  implications  of  applying  a  generic  practice  vary  for  each 
process  area.  Consider  two  examples  that  illustrate  these  differences 
as  they  relate  to  planning  the  process.  First,  the  planning  described  by 
this  generic  practice  as  applied  to  the  Project  Monitoring  and  Control 
process  area  may  be  carried  out  in  full  by  the  processes  associated 
with  the  Project  Planning  process  area.  In  such  a  situation,  the  generic 
practice  imposes  no  additional  expectations  for  planning.  Second,  the 
planning  described  by  this  generic  practice  as  applied  to  the  Project 
Planning  process  area  typically  would  not  be  addressed  by  the 
processes  associated  with  other  process  areas  in  the  model.  Therefore, 
the  generic  practice  sets  an  expectation  that  the  project  planning 
process  itself  be  planned.  It  is  important  to  be  aware  of  the  extent  to 
which  this  generic  practice  may  either  reinforce  expectations  set 
elsewhere  in  the  model,  or  set  new  expectations  that  should  be 
addressed.  [gpio4.nios] 

Establishing  a  plan  includes  documenting  the  plan  and  providing  a 
process  description.  Maintaining  the  plan  includes  changing  it  as 
necessary,  in  response  to  either  corrective  actions  or  to  changes  in 
requirements  and  objectives  for  the  process.  [gpio4.nio3] 

The  plan  for  performing  the  process  typically  includes  the  following: 

[GP104.N106] 

•  Process  description 

•  Standards  for  the  work  products  and  services  of  the  process 

•  Requirements  for  the  work  products  and  services  of  the  process 
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•  Specific  objectives  for  the  performance  of  the  process  (e.g.,  quality, 
time  scale,  cycle  time,  and  resource  usage) 

•  Dependencies  among  the  activities,  work  products,  and  services  of 
the  process 

•  Resources  (including  funding,  people,  and  tools)  needed  to 
perform  the  process 

•  Assignment  of  responsibility  and  authority 

•  Training  needed  for  performing  and  supporting  the  process 

•  Work  products  to  be  placed  under  configuration  management  and 
the  level  of  configuration  management  for  each  item 

•  Measurement  requirements  to  provide  insight  into  the  performance 
of  the  process,  its  work  products,  and  its  services 

•  Involvement  of  identified  stakeholders 

•  Activities  for  monitoring  and  controlling  the  process 

•  Objective  evaluation  activities  for  the  process  and  the  work 
products 

•  Management  review  activities  for  the  process  and  the  work 
products 

Subpractices 

1 .  Obtain  management  sponsorship  for  performing  the  process. 

[GP104.SubP101] 

2.  Define  and  document  the  process  description.  [GPio4.subPio2] 

The  process  description,  which  includes  relevant  standards  and  procedures,  may 
be  included  as  part  of  the  plan  for  performing  the  process  or  may  be  included  in 
the  plan  by  reference.  [GPio4.subPio2.Nioi] 

3.  Define  and  document  the  plan  for  performing  the  process. 

[GP104.SubP103] 

This  plan  may  be  a  stand-alone  document,  embedded  in  a  more  comprehensive 
document,  or  distributed  across  multiple  documents.  In  the  case  of  the  plan  being 
distributed  across  multiple  documents,  ensure  that  a  coherent  picture  is  preserved 
of  who  does  what.  Documents  may  be  hardcopy  or  softcopy.  [GPi04.subPi03.Ni02] 

4.  Review  the  plan  with  relevant  stakeholders  and  get  their 
agreement.  [GPio4.subPio4] 

This  includes  reviewing  that  the  planned  process  satisfies  the  applicable  policies, 
plans,  requirements,  and  standards  to  provide  assurance  to  relevant 
stakeholders.  [GPio4.subPio4.Nioi] 

5.  Revise  the  plan  as  necessary.  [GPio4.subPios] 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  the  resources 
necessary  to  perform  the  process  as  defined  by  the  plan  are  available 
when  they  are  needed.  Resources  include  adequate  funding, 
appropriate  physical  facilities,  skilled  people,  and  appropriate  tools. 

[GP105] 


The  interpretation  of  the  term  “adequate”  depends  on  many  factors  and 
may  change  over  time.  Inadequate  resources  may  be  addressed  by 
increasing  resources  or  by  removing  requirements,  constraints,  and 
commitments,  [gpios.nioi] 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process. 


The  purpose  of  this  generic  practice  is  to  ensure  that  there  is 
accountability  throughout  the  life  of  the  process  for  performing  the 
process  and  achieving  the  specified  results.  The  people  assigned  must 
have  the  appropriate  authority  to  perform  the  assigned  responsibilities. 

[GP106] 


Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in 
living  documents,  such  as  the  plan  for  performing  the  process.  Dynamic 
assignment  of  responsibility  is  another  legitimate  way  to  perform  this 
generic  practice,  as  long  as  the  assignment  and  acceptance  of 
responsibility  are  ensured  throughout  the  life  of  the  process.  [GPioe.Nioi] 

Subpractices 

1 .  Assign  overall  responsibility  and  authority  for  performing  the 
process.  [Gpm.subPioi] 

2.  Assign  responsibility  for  performing  the  specific  tasks  of  the 
process.  [GP106.SubP102] 

3.  Confirm  that  the  people  assigned  to  the  responsibilities  and 
authorities  understand  and  accept  them.  [GPioe.subPio3] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  as  needed. 
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The  purpose  of  this  generic  practice  is  to  ensure  that  the  people  have 
the  necessary  skills  and  expertise  to  perform  or  support  the  process. 

[GP107] 


Appropriate  training  is  provided  to  the  people  who  will  be  performing  the 
work.  Overview  training  is  provided  to  orient  people  who  interact  with 
those  performing  the  work,  [gpioz.nioi] 

Examples  of  methods  for  providing  training  include:  self  study;  self- 
directed  training;  self-paced,  programmed  instruction;  formalized  on- 
the-job  training;  mentoring;  and  formal  and  classroom  training,  [gpw.nkm] 

Training  supports  the  successful  performance  of  the  process  by 
establishing  a  common  understanding  of  the  process  and  by  imparting 
the  skills  and  knowledge  needed  to  perform  the  process,  [gpw.nkw] 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  under  appropriate 
levels  of  configuration  management. 


The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
integrity  of  the  designated  work  products  of  the  process  (or  their 
descriptions)  throughout  their  useful  life,  [gpiosj 

Refer  to  the  Configuration  Management  process  area  for  more 
information  on  placing  work  products  under  configuration  management. 

[GP109.R101] 


The  designated  work  products  are  specifically  identified  in  the  plan  for 
performing  the  process,  along  with  a  specification  of  the  level  of 
configuration  management.  [gpio9.nioi] 

Different  levels  of  configuration  management  are  appropriate  for 
different  work  products  and  for  different  points  in  time.  For  some  work 
products,  it  may  be  sufficient  to  maintain  version  control  (i.e.,  the 
version  of  the  work  product  in  use  at  a  given  time,  past  or  present,  is 
known  and  changes  are  incorporated  in  a  controlled  manner).  Version 
control  is  usually  under  the  sole  control  of  the  work  product  owner 
(which  may  be  an  individual,  a  group,  or  a  team).  [GP109.N102] 

Sometimes,  it  may  be  critical  that  work  products  be  placed  under  formal 
or  “baseline”  configuration  management.  This  type  of  configuration 
management  includes  defining  and  establishing  baselines  at 
predetermined  points.  These  baselines  are  formally  reviewed  and 
agreed  on,  and  serve  as  the  basis  for  further  development  of  the 
designated  work  products.  [gpio9.nio4] 
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Additional  levels  of  configuration  management  between  version  control 
and  formal  configuration  management  are  possible.  An  identified  work 
product  may  be  under  various  levels  of  configuration  management  at 
different  points  in  time.  [gpio9.nio3] 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  as  planned. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  the 
expected  involvement  of  stakeholders  during  the  execution  of  the 
process.  [gpi24] 

Involve  relevant  stakeholders  as  described  in  an  appropriate  plan  for 
stakeholder  involvement.  Involve  them  appropriately  in  activities  such 
as  the  following:  [gpi24nioij 

•  Planning 

•  Decisions 

•  Communications 

•  Coordination 

•  Reviews 

•  Appraisals 

•  Requirements  definitions 

•  Resolution  of  problems/issues 

Refer  to  the  Project  Planning  process  area  for  information  on  the  project 
planning  for  stakeholder  involvement,  [gpi24.nioi.rwi] 

The  objective  of  planning  the  stakeholder  involvement  is  to  ensure  that 
interactions  necessary  to  the  process  are  accomplished,  while  not 
allowing  excessive  numbers  of  affected  groups  and  individuals  to 
impede  process  execution.  [GP124.N102] 

Subpractices 

1 .  Identify  stakeholders  relevant  to  this  process  and  decide  what  type 
of  involvement  should  be  practiced.  [GPi24.subPioi] 

Relevant  stakeholders  are  identified  among  the  suppliers  of  inputs  to,  the  users  of 
outputs  from,  and  the  performers  of  the  activities  within  the  process.  Once  the 
relevant  stakeholders  are  identified,  the  appropriate  level  of  their  involvement  in 
process  activities  is  planned.  [GPi24.subPio1.Nioi] 

2.  Share  these  identifications  with  project  planners  or  other  planners 
as  appropriate.  [GPi24.subPio2] 

3.  Involve  relevant  stakeholders  as  planned.  [GPi24.subPio3] 
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GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  against  the  plan  for  performing 
the  process  and  take  appropriate  corrective  action. 


The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day 
monitoring  and  controlling  of  the  process.  Appropriate  visibility  into  the 
process  is  maintained  so  that  appropriate  corrective  action  can  be  taken 
when  necessary.  Monitoring  and  controlling  the  process  involves 
measuring  appropriate  attributes  of  the  process  or  work  products 
produced  by  the  process,  [gphoi 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action.  [GP110.R1021 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  measurement,  [gpuo.rioii 

Subpractices 

1 .  Measure  actual  performance  against  the  plan  for  performing  the 
process.  [GPiio.subPioi] 

The  measures  are  of  the  process,  its  work  products,  and  its  services. 

[GP110.SubP101.N101] 

2.  Review  accomplishments  and  results  of  the  process  against  the 
plan  for  performing  the  process.  [GPiio.subPioi 

3.  Review  activities,  status,  and  results  of  the  process  with  the 
immediate  level  of  management  responsible  for  the  process  and 
identify  issues.  The  reviews  are  intended  to  provide  the  immediate 
level  of  management  with  appropriate  visibility  into  the  process. 

The  reviews  can  be  both  periodic  and  event  driven.  [GPiio.subPios] 

4.  Identify  and  evaluate  the  effects  of  significant  deviations  from  the 
plan  for  performing  the  process.  [GPiio.subPio4] 

5.  Identify  problems  in  the  plan  for  performing  the  process  and  in  the 
execution  of  the  process.  [GPiio.subPios] 

6.  Take  corrective  action  when  requirements  and  objectives  are  not 
being  satisfied,  when  issues  are  identified,  or  when  progress  differs 
significantly  from  the  plan  for  performing  the  process.  [GPiio.subPioei 

There  are  inherent  risks  that  should  be  considered  before  any  of  the  corrective 
actions  are  taken.  [GPi10.subPi06.Ni02] 

Corrective  action  may  include  the  following:  [GPiio.subPioe.Nioi] 

•  Taking  remedial  action  to  repair  defective  work  products  or  services 

•  Changing  the  plan  for  performing  the  process 
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•  Adjusting  resources,  including  people,  tools,  and  other  resources 

•  Negotiating  changes  to  the  established  commitments 

•  Securing  change  to  the  requirements  and  objectives  that  have  to  be  satisfied 

•  Terminating  the  effort 

7.  Track  corrective  action  to  closure.  [GPiio.subPW] 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  against  its  process 
description,  standards,  and  procedures,  and  address 
noncompliance. 


The  purpose  of  this  generic  practice  is  to  provide  credible  assurance 
that  the  process  is  implemented  as  planned  and  adheres  to  its  process 
description,  standards,  and  procedures.  See  the  definition  of 
“objectively  evaluate”  in  Appendix  C,  the  glossary.  [gph3] 

People  not  directly  responsible  for  managing  or  performing  the  activities 
of  the  process  typically  evaluate  adherence.  In  many  cases,  adherence 
is  evaluated  by  people  within  the  organization,  but  external  to  the 
process  or  project,  or  by  people  external  to  the  organization.  As  a 
result,  credible  assurance  of  adherence  can  be  provided  even  during 
times  when  the  process  is  under  stress  (e.g.,  when  the  effort  is  behind 
schedule  or  over  budget).  [gph3.nioi] 

Refer  to  the  Process  and  Product  Quality  Assurance  process  area  for 
more  information  about  objectively  evaluating  adherence,  [gph3.nwi.rioi] 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  with 
higher  level  management  and  resolve  issues. 


The  purpose  of  this  generic  practice  is  to  provide  higher  level 
management  with  the  appropriate  visibility  into  the  process.  [gph2] 

Higher  level  management  includes  those  levels  of  management  in  the 
organization  above  the  immediate  level  of  management  responsible  for 
the  process.  In  particular,  higher  level  management  includes  senior 
management.  These  reviews  are  for  managers  who  provide  the  policy 
and  overall  guidance  for  the  process,  not  for  those  who  perform  the 
direct  day-to-day  monitoring  and  controlling  of  the  process.  [gph2.nio2] 

Different  managers  have  different  needs  for  information  about  the 
process.  These  reviews  help  ensure  that  informed  decisions  on  the 
planning  and  performing  of  the  process  can  be  made.  Therefore,  these 
reviews  are  expected  to  be  both  periodic  and  event  driven.  [gph2.nioii 
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Capability  Level  3:  Defined 


A  capability  level  3  process  is  characterized  as  a  “defined  process.” 

[CL104] 


A  defined  process  is  a  managed  (capability  level  2)  process  that  is 
tailored  from  the  organization's  set  of  standard  processes  according  to 
the  organization’s  tailoring  guidelines,  and  contributes  work  products, 
measures,  and  other  process-improvement  information  to  the 
organizational  process  assets.  [clio4.nio6] 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the 
defined  process,  are  established  and  improved  overtime.  Standard 
processes  describe  the  fundamental  process  elements  that  are 
expected  in  the  defined  processes.  Standard  processes  also  describe 
the  relationships  (e.g.,  the  ordering  and  interfaces)  between  these 
process  elements.  The  organization-level  infrastructure  to  support 
current  and  future  use  of  the  organization's  set  of  standard  processes  is 
established  and  improved  over  time.  See  the  definition  of  “standard 
process”  in  Appendix  C,  the  glossary.  See  Chapter  3  for  an  explanation 
of  how  “organization’s  set  of  standard  processes”  is  used  in  the  CMMI 
Product  Suite,  [clw.nioi] 

The  organizational  process  assets  are  artifacts  that  relate  to  describing, 
implementing,  and  improving  processes.  These  artifacts  are  assets 
because  they  are  developed  or  acquired  to  meet  the  business 
objectives  of  the  organization,  and  they  represent  investments  by  the 
organization  that  are  expected  to  provide  current  and  future  business 
value.  See  Chapter  3  for  an  explanation  of  how  “organizational  process 
assets”  is  used  in  the  CMMI  Product  Suite.  [clkm.nkk] 

A  defined  process  clearly  states  the  following:  [cho4.nio3] 

•  Purpose 

•  Inputs 

•  Entry  criteria 

•  Activities 

•  Roles 

•  Measures 

•  Verification  steps 

•  Outputs 

•  Exit  criteria 

A  defined  process  is  institutionalized  by  doing  the  following:  [cho4.nio4] 

•  Addressing  the  items  that  institutionalize  a  managed  process 
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•  Following  a  plan  that  incorporates  a  defined  process 

•  Collecting  work  products,  measures,  and  improvement  information 
for  supporting  the  use  and  improvement  of  the  organizational 
process  assets 

See  Chapter  3  for  an  explanation  of  how  “defined  process”  is  used  in 

the  CMMI  Product  Suite.  [CL104.N107] 

A  critical  distinction  between  a  managed  process  and  a  defined  process 
is  the  scope  of  application  of  the  process  descriptions,  standards,  and 
procedures.  For  a  managed  process,  the  process  descriptions, 
standards,  and  procedures  are  applicable  to  a  particular  project,  group, 
or  organizational  function.  As  a  result,  the  managed  processes  for  two 
projects  within  the  same  organization  may  be  very  different,  [clw.nios] 

At  the  defined  capability  level,  the  organization  is  interested  in 
deploying  standard  processes  that  are  proven  and  that  therefore  take 
less  time  and  money  than  continually  writing  and  deploying  new 
processes.  Because  the  process  descriptions,  standards,  and 
procedures  are  tailored  from  the  organization's  set  of  standard 
processes  and  related  organizational  process  assets,  defined 
processes  are  appropriately  consistent  across  the  organization.  Another 
critical  distinction  is  that  a  defined  process  is  described  in  more  detail 
and  performed  more  rigorously  than  a  managed  process.  This  means 
that  improvement  information  is  easier  to  understand,  analyze,  and  use. 
Finally,  management  of  the  defined  process  is  based  on  the  additional 
insight  provided  by  an  understanding  of  the  interrelationships  of  the 
process  activities  and  detailed  measures  of  the  process,  its  work 
products,  and  its  services,  [clkm.nios] 


Level  3  Generic  Goals 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process.  [clio4.glioii 


Level  3  Generic  Practices 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process. 
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The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a 
description  of  the  process  that  is  tailored  from  the  organization's  set  of 
standard  processes  to  address  the  needs  of  a  specific  instantiation.  The 
organization  should  have  standard  processes  that  cover  the  process 
area,  as  well  as  have  guidelines  for  tailoring  these  standard  processes 
to  meet  the  needs  of  a  project  or  organizational  function.  With  a  defined 
process,  variability  in  how  the  processes  are  performed  across  the 
organization  is  reduced  and  process  assets,  data,  and  learning  can  be 
effectively  shared.  [gpi-m] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization's  set  of  standard  processes  and 
tailoring  guidelines,  ig piu.rioii 

The  descriptions  of  the  defined  processes  provide  the  basis  for 
planning,  performing,  and  managing  the  activities,  work  products,  and 
services  associated  with  the  process,  [gpim.nkk] 

Subpractices 

1 .  Select  from  the  organization’s  set  of  standard  processes  those 
processes  that  cover  the  process  area  and  best  meet  the  needs  of 
the  project  or  organizational  function.  [GPiu.subPioi] 

2.  Establish  the  defined  process  by  tailoring  the  selected  processes 
according  to  the  organization’s  tailoring  guidelines.  [GPiu.subPiog 

3.  Ensure  that  the  organization’s  process  objectives  are  appropriately 
addressed  in  the  defined  process.  [GPii4.subPio3] 

4.  Document  the  defined  process  and  the  records  of  the  tailoring. 

[GP1 14.SubP104] 

5.  Revise  the  description  of  the  defined  process  as  necessary. 

[GP114.SubP106] 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  process  to  support  the  future  use  and  improvement  of  the 
organization’s  processes  and  process  assets. 


The  purpose  of  this  generic  practice  is  to  collect  information  and 
artifacts  derived  from  planning  and  performing  the  process.  This  generic 
practice  is  performed  so  that  the  information  and  artifacts  can  be 
included  in  the  organizational  process  assets  and  made  available  to 
those  who  are  (or  who  will  be)  planning  and  performing  the  same  or 
similar  processes.  The  information  and  artifacts  are  stored  in  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library.  [gph7] 
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Examples  of  relevant  information  include  the  effort  expended  for  the  various  activities, 
defects  injected  or  removed  in  a  particular  activity,  and  lessons  learned.  [gph7.nioii 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository  and 
process  asset  library  and  for  more  information  about  the  work  products, 
measures,  and  improvement  information  that  are  incorporated  into 
these  organizational  process  assets,  [gph7.nioi.rwi] 

Subpractices 

1 .  Store  process  and  product  measures  in  the  organization's 
measurement  repository.  [GPii7.subPio2] 

The  process  and  product  measures  are  primarily  those  that  are  defined  in  the 
common  set  of  measures  for  the  organization’s  set  of  standard  processes. 

[GP117.SubP102.N101] 

2.  Submit  documentation  for  inclusion  in  the  organization’s  process 
asset  library.  [GPii7.subPio3] 

3.  Document  lessons  learned  from  the  process  for  inclusion  in  the 
organization’s  process  asset  library.  [GPii7.subPio4] 

4.  Propose  improvements  to  the  organizational  process  assets. 

[GP117.SubP101] 


Capability  Level  4:  Quantitatively  Managed 


A  capability  level  4  process  is  characterized  as  a  “quantitatively 
managed  process.”  [clios] 

A  quantitatively  managed  process  is  a  defined  (capability  level  3) 
process  that  is  controlled  using  statistical  and  other  quantitative 
techniques.  Quantitative  objectives  for  quality  and  process  performance 
are  established  and  used  as  criteria  in  managing  the  process.  The 
quality  and  process  performance  are  understood  in  statistical  terms  and 
are  managed  throughout  the  life  of  the  process,  [clios.niiij 

See  Chapter  3  for  an  explanation  of  how  “quality  and  process- 
performance  objectives”  is  used  in  the  CMMI  Product  Suite.  [clio5.nh2] 

The  quantitative  objectives  are  based  on  the  capability  of  the 
organization's  set  of  standard  processes,  the  organization’s  business 
objectives,  and  the  needs  of  the  customer,  end  users,  organization,  and 
process  implementers,  subject  to  available  resources,  iclios.nioi] 


Overview 


The  people  performing  the  process  are  directly  involved  in  quantitatively 
managing  the  process,  [clios.nkk] 
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Quantitative  management  is  performed  on  the  overall  set  of  processes 
that  produces  a  product  or  provides  a  service.  The  subprocesses  that 
are  significant  contributors  to  overall  process  performance  are 
statistically  managed.  For  these  selected  subprocesses,  detailed 
measures  of  the  process  performance  are  collected  and  statistically 
analyzed.  Special  causes  of  process  variation  are  identified  and,  where 
appropriate,  the  source  of  the  special  cause  is  addressed  to  prevent 
future  occurrences.  [clios.nio3] 

The  quality  and  process  performance  measures  are  incorporated  into 
the  organization’s  measurement  repository  to  support  future  fact-based 
decision  making,  [clios.nkmi 

A  quantitatively  managed  process  is  institutionalized  by  doing  the 
following:  [chos.niosi 

•  Addressing  the  items  that  institutionalize  a  defined  process 

•  Establishing  and  maintaining  quantitative  objectives  for  quality  and 
process  performance 

•  Stabilizing  the  performance  of  subprocesses  critical  to  the 
performance  of  the  process 

•  Establishing  and  maintaining  an  understanding  of  the  ability  of  the 
process  to  achieve  the  established  quantitative  objectives  for 
quality  and  process  performance 

A  critical  distinction  between  a  defined  process  and  a  quantitatively 
managed  process  is  the  predictability  of  the  process  performance.  The 
term  “quantitatively  managed”  implies  using  appropriate  statistical  and 
other  quantitative  techniques  to  manage  the  performance  of  one  or 
more  critical  subprocesses  of  a  process  so  that  the  future  performance 
of  the  process  can  be  predicted.  A  defined  process  only  provides 
qualitative  predictability.  [cuos.Nioe] 

Activities  for  quantitatively  managing  the  performance  of  a  process 
include  the  following:  [clios.nhoi 

•  Identifying  the  subprocesses  that  are  to  be  brought  under  statistical 
management 

•  Identifying  and  measuring  product  and  process  attributes  that  are 
important  contributors  to  quality  and  process  performance 

•  Identifying  and  addressing  special  causes  of  subprocess  variations 
(based  on  the  selected  product  and  process  attributes  and 
subprocesses  selected  for  statistical  management) 

•  Managing  each  of  the  selected  subprocesses,  with  the  objective  of 
bringing  their  performance  within  natural  bounds  (i.e.,  making  the 
subprocess  performance  statistically  stable  and  predictable  based 
on  the  selected  product  and  process  attributes) 
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•  Predicting  the  ability  of  the  process  to  satisfy  established 
quantitative  quality  and  process-performance  objectives 

•  Taking  appropriate  corrective  actions  when  it  is  determined  that  the 
established  quantitative  quality  and  process-performance 
objectives  will  not  be  satisfied 

The  corrective  actions  described  above  include  changing  the  objectives 
or  ensuring  that  relevant  stakeholders  have  a  quantitative 
understanding  of,  and  have  agreed  to,  the  performance  shortfall. 

[CL105.N109] 


Level  4  Generic  Goals 


GG  4  Institutionalize  a  Quantitatively  Managed  Process 


The  process  is  institutionalized  as  a  quantitatively  managed  process,  [clios.glioij 


Level  4  Generic  Practices 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  process  that 
address  quality  and  process  performance  based  on  customer 
needs  and  business  objectives. 


The  purpose  of  this  generic  practice  is  to  determine  and  obtain 
agreement  from  relevant  stakeholders  about  specific  quantitative 
objectives  for  the  process.  These  quantitative  objectives  can  be 
expressed  in  terms  of  product  quality,  service  quality,  and  process 
performance,  [gphsj 

Refer  to  the  Quantitative  Project  Management  process  area  for 
information  on  how  quantitative  objectives  are  set  for  subprocesses  of 
the  project’s  defined  process,  [gphb.rioii 

The  quantitative  objectives  may  be  specific  to  the  process  or  they  may 
be  defined  for  a  broader  scope  (e.g.,  for  a  set  of  processes).  In  the 
latter  case,  these  quantitative  objectives  may  be  allocated  to  some  of 
the  included  processes,  [gphs.nioi] 
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These  quantitative  objectives  are  criteria  used  to  judge  whether  the 
products,  services,  and  process  performance  will  satisfy  the  customers, 
end  users,  organization  management,  and  process  implementers. 
These  quantitative  objectives  go  beyond  the  traditional  end-product 
objectives.  They  also  cover  intermediate  objectives  that  are  used  to 
manage  the  achievement  of  the  objectives  over  time.  They  reflect,  in 
part,  the  demonstrated  performance  of  the  organization's  set  of 
standard  processes.  These  quantitative  objectives  should  be  set  to 
values  that  are  likely  to  be  achieved  when  the  processes  involved  are 
stable  and  within  their  natural  bounds.  [gpiisnio2] 

Subpractices 

1 .  Establish  the  quantitative  objectives  that  pertain  to  the  process. 

[GP118.SubP101] 

2.  Allocate  the  quantitative  objectives  to  the  process  or  its 
subprocesses.  [GPiis.subPio2] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives. 


The  purpose  of  this  generic  practice  is  to  stabilize  the  performance  of 
one  or  more  subprocesses  of  the  defined  (capability  level  3)  process 
that  are  critical  contributors  to  the  overall  performance  using 
appropriate  statistical  and  other  quantitative  techniques.  Stabilizing 
selected  subprocesses  of  the  process  supports  predicting  the  ability  of 
the  process  to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives.  [gph9] 

A  stable  subprocess  shows  no  significant  indication  of  special  causes  of 
process  variation.  Stable  subprocesses  are  predictable  within  the  limits 
established  by  the  natural  bounds  of  the  subprocess.  Variations  in  the 
stable  subprocess  are  due  to  a  constant  system  of  chance  causes,  and 
the  magnitude  of  the  variations  may  be  small  or  large.  [gpii9.nio3] 

Predicting  the  ability  of  the  process  to  achieve  the  established 
quantitative  objectives  requires  a  quantitative  understanding  of  the 
contributions  of  the  subprocesses  that  are  critical  to  achieving  these 
objectives  and  establishing  and  managing  against  interim  quantitative 
objectives  overtime.  [gph9nio4] 

Selected  process  and  product  measures  are  incorporated  into  the 
organization’s  measurement  repository  to  support  process  performance 
analysis  and  future  fact-based  decision  making.  [gph9.nioii 
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Subpractices 

1 .  Statistically  manage  the  performance  of  one  or  more  subprocesses 
that  are  critical  contributors  to  the  overall  performance  of  the 
process.  [GPiiasubPioi] 

2.  Predict  the  ability  of  the  process  to  achieve  its  established 
quantitative  objectives  considering  the  performance  of  the 
statistically  managed  subprocesses.  [GPii9.subPio2] 

3.  Incorporate  selected  process  performance  measurements  into  the 
organization’s  process  performance  baselines.  [GPii9.subPio3] 


Capability  Level  5:  Optimizing 


A  capability  level  5  process  is  characterized  as  an  “optimizing  process.” 

[CL106] 


An  optimizing  process  is  a  quantitatively  managed  (capability  level  4) 
process  that  is  changed  and  adapted  to  meet  relevant  current  and 
projected  business  objectives.  An  optimizing  process  focuses  on 
continually  improving  the  process  performance  through  both 
incremental  and  innovative  technological  improvements.  Process 
improvements  that  would  address  root  causes  of  process  variation  and 
measurably  improve  the  organization’s  processes  are  identified, 
evaluated,  and  deployed  as  appropriate.  These  improvements  are 
selected  based  on  a  quantitative  understanding  of  their  expected 
contribution  to  achieving  the  organization’s  process-improvement 
objectives  versus  the  cost  and  impact  to  the  organization.  The  process 
performance  of  the  organization’s  processes  is  continually  improved. 

[CL106.N107] 


Selected  incremental  and  innovative  technological  process 
improvements  are  systematically  managed  and  deployed  into  the 
organization.  The  effects  of  the  deployed  process  improvements  are 
measured  and  evaluated  against  the  quantitative  process-improvement 
objectives.  [clio6.nio3] 

An  optimizing  process  is  institutionalized  by  doing  the  following: 

[CL106.N104] 

•  Satisfying  the  items  that  institutionalize  a  quantitatively  managed 
process 

•  Establishing  and  maintaining  quantitative  process-improvement 
objectives 

•  Identifying  and  deploying  both  incremental  and  innovative 
technological  improvements  that  continually  improve  the  range  of 
process  performance 
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A  critical  distinction  between  a  quantitatively  managed  process  and  an 
optimizing  process  is  that  the  optimizing  process  is  continuously 
improved  by  addressing  common  causes  of  process  variation.  A 
quantitatively  managed  process  is  concerned  with  addressing  special 
causes  of  process  variation  and  providing  statistical  predictability  for  the 
results.  Though  the  process  may  produce  predictable  results,  the 
results  may  be  insufficient  to  achieve  the  established  objectives.  In  a 
process  that  is  optimized,  common  causes  of  process  variation  are 
addressed  by  changing  that  process  in  a  manner  that  will  lead  to  a  shift 
in  the  mean  or  a  decrease  in  variation  when  it  is  brought  back  to 
stability.  These  changes  are  intended  to  improve  process  performance 
and  achieve  the  organization’s  established  process-improvement 
objectives.  [clio6.nios] 

A  common  cause  of  process  variation  is  a  cause  that  is  inherently  part 
of  a  process  and  affects  the  overall  performance  of  the  process.  See 
the  definition  of  “common  cause  of  process  variation’’  in  Appendix  C, 
the  glossary.  [clio6.nio6] 


Level  5  Generic  Goals 


GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process,  [clwb.glioii 


Level  5  Generic  Practices 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  process  in  fulfilling  the 
relevant  business  objectives  of  the  organization. 


The  purpose  of  this  generic  practice  is  to  select  and  systematically 
deploy  process  and  technology  improvements  that  contribute  to 
meeting  established  quality  and  process-performance  objectives.  [gpi25] 

Optimizing  processes  that  are  agile  and  innovative  depends  on  the 
participation  of  an  empowered  workforce  aligned  with  the  business 
values  and  objectives  of  the  organization.  The  organization’s  ability  to 
rapidly  respond  to  changes  and  opportunities  is  enhanced  by  finding 
ways  to  accelerate  and  share  learning.  Improvement  of  the  processes  is 
inherently  part  of  everybody’s  role,  resulting  in  a  cycle  of  continual 
improvement.  [gpi25.nioi] 
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Subpractices 

1.  Establish  and  maintain  quantitative  process-improvement 
objectives  that  support  the  organization’s  business  objectives. 

[GP125.SubP101] 


The  quantitative  process-improvement  objectives  may  be  specific  to  the  individual 
process  or  they  may  be  defined  for  a  broader  scope  (i.e.,  for  a  set  of  processes), 
with  the  individual  processes  contributing  to  achieving  these  objectives. 

Objectives  that  are  specific  to  the  individual  process  are  typically  allocated  from 
quantitative  objectives  established  for  a  broader  scope.  [GPi25.subPio1.Nioi] 

These  process-improvement  objectives  are  primarily  derived  from  the 
organization’s  business  objectives  and  from  a  detailed  understanding  of  process 
capability.  These  objectives  are  the  criteria  used  to  judge  whether  the  process 
performance  is  quantitatively  improving  the  organization’s  ability  to  meet  its 
business  objectives.  These  process-improvement  objectives  are  often  set  to 
values  beyond  the  current  process  performance,  and  both  incremental  and 
innovative  technological  improvements  may  be  needed  to  achieve  these 
objectives.  These  objectives  may  also  be  revised  frequently  to  continue  to  drive 
the  improvement  of  the  process  (i.e.,  when  an  objective  is  achieved,  it  may  be  set 
to  a  new  value  that  is  again  beyond  the  new  process  performance).  [GPi25.subPio1.Nio2] 

These  process-improvement  objectives  may  be  the  same  as,  or  a  refinement  of, 
the  objectives  established  in  the  Establish  Quantitative  Objectives  for  the  Process 
generic  practice,  as  long  as  they  can  serve  as  both  drivers  and  criteria  for 
successful  process  improvement.  [GPi25.subPi01.Ni03] 

2.  Identify  process  improvements  that  would  result  in  measurable 
improvements  to  process  performance.  [GPi25.subPio2] 

Process  improvements  include  both  incremental  changes  and  innovative 
technological  improvements.  The  innovative  technological  improvements  are 
typically  pursued  as  efforts  that  are  separately  planned,  performed,  and  managed. 
Piloting  is  often  performed.  These  efforts  often  address  specific  areas  of  the 
processes  that  are  determined  by  analyzing  the  process  performance  and 
identifying  specific  opportunities  for  significant  measurable  improvement. 

[GP125.SubP102.N101] 

3.  Define  strategies  and  manage  deployment  of  selected  process 
improvements  based  on  the  quantified  expected  benefits,  the 
estimated  costs  and  impacts,  and  the  measured  change  to  process 
performance.  [GPi25.subPio3] 

The  costs  and  benefits  of  these  improvements  are  estimated  quantitatively,  and 
the  actual  costs  and  benefits  are  measured.  Benefits  are  primarily  considered 
relative  to  the  organization’s  quantitative  process-improvement  objectives. 
Improvements  are  made  to  both  the  organization’s  set  of  standard  processes  and 
the  defined  processes.  [GPi25.subPio3.Nioi] 
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Managing  deployment  of  the  process  improvements  includes  piloting  of  changes 
and  implementing  adjustments  where  appropriate,  addressing  potential  and  real 
barriers  to  the  deployment,  minimizing  disruption  to  ongoing  efforts,  and 
managing  risks.  [GPi25.subPi03.Ni02] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  process. 


The  purpose  of  this  generic  practice  is  to  analyze  defects  and  other 
problems  that  were  encountered,  to  correct  the  root  causes  of  these 
types  of  defects  and  problems,  and  to  prevent  these  defects  and 
problems  from  occurring  in  the  future.  [GP121] 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  on  identifying  and  correcting  root  causes  of  selected 
defects.  Even  though  the  Causal  Analysis  and  Resolution  process  area 
has  a  project  context,  it  can  be  applied  to  processes  in  other  contexts 
as  well.  [GP121.R101] 
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5  Framework  Interactions 


The  CMMI  Product  Suite  was  developed  using  a  consensus-based 
approach  to  identifying  and  describing  best  practices  in  a  variety  of 
disciplines.  Successful  process-improvement  initiatives  must  be  driven 
by  the  business  objectives  of  the  organization.  [FM102.T103] 

For  example,  a  common  business  objective  is  to  reduce  the  time  it 
takes  to  get  a  product  to  market.  The  process-improvement  objective 
derived  from  that  might  be  to  improve  the  Project  Management 
processes  to  ensure  on-time  delivery  and  would  be  those  found  in  the 
Project  Planning  and  Project  Monitoring  and  Control  process  areas. 

[FM102.T106] 


In  this  chapter,  interactions  among  process  areas  are  described  that 
help  you  to  see  the  enterprise  view  of  process  improvement.  The 
process  areas  discussed  and  illustrated  include  the  IPPD  and  supplier 
sourcing  material  that  is  specific  to  models  that  include  the  IPPD  and 
supplier  sourcing  disciplines.  If  you  are  not  using  a  model  that  includes 
IPPD  or  supplier  sourcing,  you  may  ignore  the  material  that  is  specific 
to  these  disciplines.  Whenever  possible,  a  statement  is  provided  to  let 
you  know  which  information  is  specific  to  IPPD  or  supplier  sourcing. 

[FM102.T101] 


Where  the  Integrated  Project  Management  (IPM)  process  area  is 
mentioned  in  this  chapter,  it  will  refer  to  IPM  for  IPPD.  Interactions  of 
the  IPM  for  IPPD  process  area  with  the  Integrated  Teaming  (IT)  and 
Organizational  Environment  for  Integration  (OEI)  are  described  in  this 
chapter.  These  process  areas  (IT  and  OEI)  are  only  included  in  Chapter 
7  if  you  have  chosen  IPPD.  The  Integrated  Supplier  Management  (ISM) 
process  area  is  only  included  in  Chapter  7  if  you  have  chosen  supplier 
sourcing.  [FM102.T102] 


Four  Categories  of  CMMI  Process  Areas 

Process  areas  can  be  grouped  into  four  categories:  [fmio2.hdaioi.tio2] 

•  Process  Management 

•  Project  Management 

•  Engineering 
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•  Support 

Although  we  are  grouping  process  areas  this  way  to  discuss  their 
interactions,  process  areas  often  interact  and  have  an  effect  on  one 
another  regardless  of  their  defined  group.  For  example,  the  Decision 
Analysis  and  Resolution  process  area  provides  specific  practices 
addressing  formal  evaluation  that  are  used  in  the  Technical  Solution 
process  area  for  selecting  a  technical  solution  from  alternative 
solutions.  Technical  Solution  is  an  Engineering  process  area  and 
Decision  Analysis  and  Resolution  is  a  Support  process  area. 

[FM102.HDA101.T103] 


The  Engineering  process  areas  are  written  in  a  general  engineering 
terminology  so  any  technical  discipline  involved  in  the  product 
development  process  (e.g.,  software  engineering,  mechanical 
engineering)  can  use  them  for  process  improvement.  The  Process 
Management,  Project  Management,  and  Support  process  areas  also 
apply  to  all  such  disciplines,  as  well  as  others,  [fmio2.hdaioi.tio5] 

You  must  be  aware  of  the  interactions  that  exist  among  CMMI  model 
components  to  apply  the  model  in  a  useful  and  productive  way.  The 
following  sections  describe  those  interactions,  [fmio2.hdaioi.tio6] 


Process  Management 


The  Scope  of  Process  Management 

Process  Management  process  areas  contain  the  cross-project  activities 
related  to  defining,  planning,  resourcing,  deploying,  implementing, 
monitoring,  controlling,  appraising,  measuring,  and  improving 

processes.  [FMi02.HDAi02.HDBi01.Ti02] 

Remember  to  focus  on  the  information  relevant  to  your  organization  and 
included  in  the  model  you  are  using,  [fmio2hdaio2.hdbioi.tio3] 

The  Process  Management  process  areas  of  CMMI  are  as  follows: 

[FM102.HDA102.HDB101.T104] 

•  Organizational  Process  Focus 

•  Organizational  Process  Definition 

•  Organizational  Training 

•  Organizational  Process  Performance 

•  Organizational  Innovation  and  Deployment 

To  describe  the  interactions  among  the  Process  Management  process 
areas,  it  is  most  useful  to  address  them  in  two  process  area  groups: 

[FM102.HDA102.HDB101.T105] 
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•  The  basic  Process  Management  process  areas  are  Organizational 
Process  Focus,  Organizational  Process  Definition,  and 
Organizational  Training. 

•  The  advanced  Process  Management  process  areas  are 
Organizational  Process  Performance  and  Organizational 
Innovation  and  Deployment. 

Basic  Process  Management  Process  Areas 

The  basic  Process  Management  process  areas  provide  the  organization 
with  a  basic  capability  to  document  and  share  best  practices, 
organizational  process  assets,  and  learning  across  the  organization. 

[FM102.HDA102.HDB102.T101] 


Figure  2  provides  a  bird’s-eye  view  of  the  interactions  among  the  basic 

Process  Management  process  areas  and  with  other  process  area 
<  ■  2 

categories.  [FMIO2.HDAIO2.HDBIO2.TIO2 


Figure  2:  Basic  Process  Management  Process  Areas 

[FM102.HDA  102.HDB102.  T103] 


2  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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As  illustrated  in  Figure  2,  the  Organizational  Process  Focus  process 
area  helps  the  organization  to  plan  and  implement  organizational 
process  improvement  based  on  an  understanding  of  the  current 
strengths  and  weaknesses  of  the  organization’s  processes  and  process 
assets.  Candidate  improvements  to  the  organization’s  processes  are 
obtained  through  various  means.  These  include  process-improvement 
proposals,  measurement  of  the  processes,  lessons  learned  in 
implementing  the  processes,  and  results  of  process  appraisal  and 
product  evaluation  activities,  [fmio2  hdaio2.hdbio2.tio4] 

The  Organizational  Process  Definition  process  area  establishes  and 
maintains  the  organization’s  set  of  standard  processes  and  other  assets 
based  on  the  process  needs  and  objectives  of  the  organization.  These 
other  assets  include  descriptions  of  processes  and  process  elements, 
descriptions  of  life-cycle  models,  process  tailoring  guidelines,  process- 
related  documentation,  and  data.  Projects  tailor  the  organization’s  set  of 
standard  processes  to  create  their  defined  processes.  The  other  assets 
support  tailoring  as  well  as  implementation  of  the  defined  processes. 
Experiences  and  work  products  from  performing  these  defined 
processes,  including  measurement  data,  process  descriptions,  process 
artifacts,  and  lessons  learned,  are  incorporated  as  appropriate  into  the 
organization’s  set  of  standard  processes  and  other  assets. 

[FM102.HDA102.HDB102.T105] 


The  Organizational  Training  process  area  identifies  the  strategic 
training  needs  of  the  organization  as  well  as  the  tactical  training  needs 
that  are  common  across  projects  and  support  groups.  In  particular, 
training  is  developed  or  obtained  that  develops  the  skills  required  to 
perform  the  organization’s  set  of  standard  processes.  The  main 
components  of  training  include  a  managed  training-development 
program,  documented  plans,  personnel  with  appropriate  knowledge, 
and  mechanisms  for  measuring  the  effectiveness  of  the  training 

program.  [FMIO2.HDAIO2.HDBIO2.TIO8] 

Advanced  Process  Management  Process  Areas 

The  advanced  Process  Management  process  areas  provide  the 
organization  with  an  advanced  capability  to  achieve  its  quantitative 
objectives  for  quality  and  process  performance,  [fmio2.hdaio2.hdbio3.tioi] 
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Figure  3  provides  a  bird’s-eye  view  of  the  interactions  among  the 
advanced  Process  Management  process  areas  and  with  other  process 
area  categories.3  Each  of  the  advanced  Process  Management  process 
areas  is  strongly  dependent  on  the  ability  to  develop  and  deploy 
process  and  supporting  assets.  The  basic  Process  Management 
process  areas  provide  this  ability.  Thus,  you  should  not  try  to  reach  a 
capability  level  for  an  advanced  Process  Management  process  area  (up 
through  capability  level  3)  prior  to  achieving  that  same  capability  level 
for  all  of  the  basic  Process  Management  process  areas. 

[FM102.HDA102.HDB103.T103 


Cost  and  benefit 


Figure  3:  Advanced  Process  Management  Process  Areas 

[FM102.HDA  102.HDB103.  T105] 


As  illustrated  in  Figure  3,  the  Organizational  Process  Performance 
process  area  derives  quantitative  objectives  for  quality  and  process 
performance  from  the  organization’s  business  objectives.  The 
organization  provides  projects  and  support  groups  with  common 
measures,  process  performance  baselines,  and  process  performance 
models.  These  additional  organizational  support  assets  support 
quantitative  project  management  and  statistical  management  of  critical 
subprocesses  for  both  projects  and  support  groups.  The  organization 
analyzes  the  process  performance  data  collected  from  these  defined 
processes  to  develop  a  quantitative  understanding  of  product  quality, 
service  quality,  and  process  performance  of  the  organization’s  set  of 
standard  processes,  [fmio2.hdaio2.hdbio3.tio6] 

3  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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The  Organizational  Innovation  and  Deployment  process  area  selects 
and  deploys  proposed  incremental  and  innovative  improvements  that 
improve  the  organization’s  ability  to  meet  its  quality  and  process- 
performance  objectives.  The  identification  of  promising  incremental  and 
innovative  improvements  should  involve  the  participation  of  an 
empowered  workforce  aligned  with  the  business  values  and  objectives 
of  the  organization.  The  selection  of  improvements  to  deploy  is  based 
on  a  quantitative  understanding  of  the  potential  benefits  and  costs  from 
deploying  candidate  improvements,  and  the  available  funding  for  such 

deployment.  [FM102.HDA102.HDB103.T107] 


Project  Management 


The  Scope  of  Project  Management 

Project  Management  process  areas  cover  the  project  management 
activities  related  to  planning,  monitoring,  and  controlling  the  project. 

[FM102.HDA103.HDB101.T107] 


Remember  to  focus  on  the  information  relevant  to  your  organization  and 
included  in  the  model  you  are  using,  [fmio2hdaio3.hdbioi.tios] 

The  Project  Management  process  areas  of  CMMI  are  as  follows: 

[FM102.HDA103.HDB101.T1 10] 

•  Project  Planning 

•  Project  Monitoring  and  Control 

•  Supplier  Agreement  Management 

•  Integrated  Project  Management  for  IPPD  (or  Integrated  Project 
Management) 

•  Risk  Management 

•  Integrated  Teaming 

•  Integrated  Supplier  Management 

•  Quantitative  Project  Management 

To  describe  the  interactions  among  the  Project  Management  process 
areas,  it  is  most  useful  to  address  them  in  two  process  area  groups: 

[FM102.HDA103.HDB101.T104] 

•  The  basic  Project  Management  process  areas  are  Project 
Planning,  Project  Monitoring  and  Control,  and  Supplier  Agreement 
Management. 

•  The  advanced  Project  Management  process  areas  are  Integrated 
Project  Management  for  IPPD,  Risk  Management,  Integrated 
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Teaming,  Quantitative  Project  Management,  and  Integrated 
Supplier  Management. 

Basic  Project  Management  Process  Areas 

The  basic  Project  Management  process  areas  address  the  basic 
activities  related  to  establishing  and  maintaining  the  project  plan, 
establishing  and  maintaining  commitments,  monitoring  progress  against 
the  plan,  taking  corrective  action,  and  managing  supplier  agreements. 

[FM102.HDA103.HDB102.T101] 


Figure  4  provides  a  bird’s-eye  view  of  the  interactions  among  the  basic 
Project  Management  process  areas  and  with  other  process  area 
categories.4  [fmio2.hdaio3.hdbio2.tio2 


Figure  4:  Basic  Project  Management  Process  Areas 

[FM102.HDA  103.HDB102.  T104] 


As  illustrated  in  Figure  4,  the  Project  Planning  process  area  includes 
developing  the  project  plan,  involving  stakeholders  appropriately, 
obtaining  commitment  to  the  plan,  and  maintaining  the  plan.  When 
using  an  IPPD  approach,  stakeholders  represent  not  just  the  technical 
expertise  for  product  and  process  development,  but  also  the  business 
implications  of  the  product  and  process  development. 

[FM 1 02.HDA1 03.HDB1 02.T1 06] 


4  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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Planning  begins  with  requirements  that  define  the  product  and  project 
(“What  to  Build”  in  the  figure).  The  project  plan  covers  the  various 
project  management  and  engineering  activities  that  will  be  performed  by 
the  project.  The  project  will  review  other  plans  that  affect  the  project 
from  various  relevant  stakeholders  and  establish  commitments  with 
those  relevant  stakeholders  for  their  contributions  to  the  project.  For 
example,  these  plans  cover  process  appraisals,  product  evaluations, 
configuration  management,  and  measurement  and  analysis. 

[FM102.HDA103.HDB102.T107] 


The  Project  Monitoring  and  Control  process  area  includes  monitoring 
activities  and  taking  corrective  action.  The  project  plan  specifies  the 
appropriate  level  of  project  monitoring,  the  frequency  of  progress 
reviews,  and  the  measures  used  to  monitor  progress.  Progress  is 
primarily  determined  by  comparing  progress  to  the  plan.  When  actual 
status  deviates  significantly  from  the  expected  values,  corrective 
actions  are  taken  as  appropriate.  These  actions  may  include  re¬ 
planning.  [FM102.HDA103.HDB102.T108] 

The  Supplier  Agreement  Management  process  area  addresses  the 
need  of  the  project  to  effectively  acquire  those  portions  of  work  that  are 
produced  by  suppliers.  Once  a  product  component  is  identified  and  the 
supplier  who  will  produce  it  is  selected,  a  supplier  agreement  is 
established  and  maintained  that  will  be  used  to  manage  the  supplier. 
The  supplier’s  progress  and  performance  are  monitored.  Acceptance 
reviews  and  tests  are  conducted  on  the  supplier-produced  product 

component.  [FM102.HDA103.HDB102.T109] 

Advanced  Project  Management  Process  Areas 

The  advanced  Project  Management  process  areas  address  activities 
such  as  establishing  a  defined  process  that  is  tailored  from  the 
organization’s  set  of  standard  processes,  coordinating  and  collaborating 
with  relevant  stakeholders  (including  suppliers),  risk  management, 
forming  and  sustaining  integrated  teams  for  the  conduct  of  projects,  and 
quantitatively  managing  the  project’s  defined  process. 

[FM102.HDA103.HDB103.T102] 


Figure  5  provides  a  bird’s-eye  view  of  the  interactions  among  the 
advanced  Project  Management  process  areas  and  with  other  process 
area  categories.  Each  of  the  advanced  Project  Management  process 
areas  is  strongly  dependent  on  the  ability  to  plan,  monitor,  and  control 
the  project.  The  basic  Project  Management  process  areas  provide  this 

ability.5  [FM102.HDA103.HDB103.T103 


5  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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Process  Performance 
objectives,  baselines,  models 


Risk  exposure  due  to 
unstable  processes 


Figure  5:  Advanced  Project  Management  Process  Areas 

[FM102.HDA  103.HDB103.  T105] 


Both  versions  of  the  Integrated  Project  Management  process  area  (IPM 
and  IPM  for  IPPD)  establish  and  maintain  the  project’s  defined  process 
that  is  tailored  from  the  organization’s  set  of  standard  processes.  The 
project  is  managed  using  the  project’s  defined  process.  The  project 
uses  and  contributes  to  the  organization’s  process  assets. 

[FM102.HDA103.HDB103.T108] 


The  project  ensures  that  the  relevant  stakeholders  associated  with  the 
project  coordinate  their  efforts  in  a  timely  manner.  It  does  this  by 
providing  for  the  management  of  stakeholder  involvement;  the 
identification,  negotiation,  and  tracking  of  critical  dependencies;  and  the 
resolution  of  coordination  issues  within  the  project  with  relevant 
stakeholders,  [fmio2.hdaio3.hdbio3.tho] 

The  following  paragraph  is  only  applicable  to  models  containing  IPPD. 

[FM102.HDA103.HDB103.T120] 
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The  Integrated  Project  Management  for  IPPD  process  area  also  creates 
the  shared  vision  for  the  project.  This  shared  vision  should  align  both 
horizontally  and  vertically  with  both  the  organization’s  and  integrated 
team’s  shared  visions,  created  in  the  Organizational  Environment  for 
Integration  and  Integrated  Teaming  process  areas,  respectively.  These 
shared  visions  collectively  support  the  coordination  and  collaboration 
among  stakeholders.  Finally,  the  Integrated  Project  Management  for 
IPPD  process  area  implements  an  integrated  team  structure  to  perform 
the  work  of  the  project  in  developing  a  product.  This  team  structure  is 
typically  based  on  the  decomposition  of  the  product  itself,  much  like  a 
work  breakdown  structure.  This  activity  is  accomplished  in  conjunction 
with  the  Integrated  Teaming  process  area,  [fmio2.hdaio3.hdbio3.tih] 

Although  risk  identification  and  monitoring  are  covered  in  the  Project 
Planning  and  Project  Monitoring  and  Control  process  areas,  the  Risk 
Management  process  area  takes  a  more  continuing,  forward-looking 
approach  to  managing  risks  with  activities  that  include  identification  of 
risk  parameters,  risk  assessments,  and  risk  handling. 

[FM102.HDA103.HDB103.T1 12] 


The  Quantitative  Project  Management  process  area  applies  quantitative 
and  statistical  techniques  to  manage  process  performance  and  product 
quality.  Quality  and  process-performance  objectives  for  the  project  are 
based  on  those  established  by  the  organization.  The  project’s  defined 
process  comprises,  in  part,  process  elements  and  subprocesses  whose 
process  performance  can  be  predicted.  At  a  minimum,  the  process 
variation  experienced  by  subprocesses  that  is  critical  to  achieving  the 
project’s  quality  and  process-performance  objectives  is  understood. 
Corrective  action  is  taken  when  special  causes  of  process  variation  are 
identified.  See  the  definition  of  “special  cause  of  process  variation”  in 
Appendix  C,  the  glossary,  [fmio2.hdaio3.hdbio3.th4] 

The  following  paragraph  is  only  applicable  to  models  containing  IPPD. 

[FM102.HDA103.HDB103.T121] 


The  specific  practices  in  the  Integrated  Teaming  process  area  provide 
for  the  formation  and  sustainment  of  each  integrated  team.  Part  of 
sustaining  the  team  is  developing  the  integrated  team’s  shared  vision, 
which  must  align  with  the  project’s  and  organization’s  shared  visions, 
developed  in  the  Integrated  Project  Management  for  IPPD  and 
Organizational  Environment  for  Integration  process  areas,  respectively. 
The  specific  practices  in  the  Organizational  Environment  for  Integration 
and  Integrated  Teaming  process  areas  then  set  the  environment  for 
enabling  integrated  teamwork.  In  addition,  the  Integrated  Teaming 
process  area  interacts  with  other  Project  Management  processes  by 
supplying  team  commitments,  work  plans,  and  other  information  that 
forms  the  basis  for  managing  the  project  and  supporting  risk 
management,  [fmio2.hdaio3.hdbio3.th6] 
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The  following  paragraphs  are  only  applicable  to  models  containing 
supplier  sourcing,  [fmio2.hdaio3.hdbio3.ti22] 

The  Integrated  Supplier  Management  process  area  proactively 
identifies  sources  of  products  that  may  be  used  to  satisfy  project 
requirements  and  monitors  selected  supplier  work  products  and 
processes  while  maintaining  a  cooperative  project-supplier  relationship. 
The  specific  practices  of  the  Integrated  Supplier  Management  process 
area  cover  selecting  potential  sources  of  products,  evaluating  those 
sources  to  select  suppliers,  monitoring  selected  supplier  processes  and 
work  products,  and  revising  the  supplier  agreement  or  relationship  as 
appropriate.  The  Integrated  Supplier  Management  process  area  works 
closely  with  the  Supplier  Agreement  Management  process  area  during 
the  supplier  selection  process.  Integrated  Supplier  Management  also 
shares  monitoring  information  with  the  Engineering  and  Support 
process  areas  in  the  form  of  technical  solution,  product  integration,  and 
validation  data  as  well  as  process  and  product  quality  assurance  and 
configuration  management  data,  [fmio2.hdaio3.hdbio3.ti23] 


Engineering 


The  Scope  of  Engineering 

Engineering  process  areas  cover  the  development  and  maintenance 
activities  that  are  shared  across  engineering  disciplines  (e.g.,  systems 
engineering  and  software  engineering).  The  six  process  areas  in  the 
Engineering  process  area  category  have  inherent  interrelationships. 
These  interrelationships  stem  from  applying  a  product  development 
process  rather  than  discipline-specific  processes  such  as  software 
engineering  or  systems  engineering,  [fmio2.hdaio4  hdbioi.tioi] 

Remember  to  focus  on  the  information  relevant  to  your  organization  and 
included  in  the  model  you  are  using,  [fmio2.hdaio4.hdbioi.tio3] 

The  Engineering  process  areas  of  CMMI  are  as  follows: 

[FM102.HDA104.HDB101.T102] 

•  Requirements  Development 

•  Requirements  Management 

•  Technical  Solution 

•  Product  Integration 

•  Verification 

•  Validation 
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Interactions  Among  Engineering  Process  Areas 

The  Engineering  process  areas  integrate  software-engineering  and 
systems-engineering  processes  into  a  product-oriented  process- 
improvement  scenario.  Improving  product  development  processes 
targets  essential  business  objectives,  rather  than  specific  disciplines. 
This  approach  to  processes  effectively  avoids  the  tendency  toward  an 
organizational  “stovepipe”  mentality,  [fmio2.hdaio4  hdbio2.tioi] 

The  technical  foundation  for  IPPD  is  grounded  in  a  robust  systems- 
engineering  approach  that  encompasses  development  in  the  context  of 
the  phases  of  the  product’s  life,  such  as  that  provided  in  the 
Engineering  process  areas  of  the  CMMI-SE/SW  model.  Thus,  the 
implementation  of  IPPD  provides  amplifications  to  specific  practices  in 
the  Engineering  process  areas  that  emphasize  concurrent  development 
and  focus  on  all  phases  of  the  product’s  life,  [fmio2.hdaio4  hdbio2.tio2] 

The  Engineering  process  areas  apply  to  the  development  of  any 
product  or  service  in  the  engineering  development  domain  (e.g., 
software  products,  hardware  products,  services,  or  processes). 

[FM102.HDA104.HDB102.T103] 


Figure  6  provides  a  bird’s-eye  view  of  the  interactions  among 
Engineering  process  areas.6  [fmio2.hdaio4.hdbio2.tio4 


Customer  needs 


Figure  6:  Engineering  Process  Areas  [fmio2.hdaio4.hdbio2.tw6] 


6  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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The  Requirements  Development  process  area  identifies  customer 
needs  and  translates  these  needs  into  product  requirements.  The  set  of 
product  requirements  is  analyzed  to  produce  a  high-level  conceptual 
solution.  This  set  of  requirements  is  then  allocated  to  a  set  of  product- 
component  requirements.  Other  requirements  that  help  define  the 
product  are  derived  and  allocated  to  product  components.  This  set  of 
product  and  product-component  requirements  clearly  describes  the 
product's  performance,  design  features,  verification  requirements,  etc. 
in  terms  the  developer  understands  and  uses,  [fmio2  hdaio4.hdbio2.ti24] 

The  Requirements  Development  process  area  supplies  requirements  to 
the  Technical  Solution  process  area,  where  the  requirements  are 
converted  into  the  product  architecture,  product-component  design,  and 
the  product  component  itself  (e.g.,  coding,  fabrication).  Requirements 
are  also  supplied  to  the  Product  Integration  process  area,  where 
product  components  are  combined  and  interfaces  are  ensured  to  meet 
the  interface  requirements  supplied  by  Requirements  Development. 

[FM102.HDA104.HDB102.T1 11] 


The  Requirements  Management  process  area  maintains  the 
requirements.  It  describes  activities  for  obtaining  and  controlling 
requirement  changes  and  ensuring  that  other  relevant  plans  and  data 
are  kept  current.  It  provides  traceability  of  requirements  from  customer 
to  product,  to  product  component,  [fmio2.hdaio4  hdbio2.th2] 

Requirements  Management  ensures  that  changes  to  requirements  are 
reflected  in  project  plans,  activities,  and  work  products.  This  cycle  of 
changes  may  impact  all  the  other  Engineering  process  areas;  thus 
requirements  management  is  a  dynamic  and  often  recursive  sequence 
of  events.  Establishment  and  maintenance  of  the  Requirements 
Management  process  area  is  fundamental  to  a  controlled  and 
disciplined  engineering  design  process,  [fmio2.hdaio4.hdbio2.th3] 

The  Technical  Solution  process  area  develops  technical  data  packages 
for  product  components  that  will  be  used  by  the  Product  Integration 
process  area.  The  examination  of  alternative  solutions,  with  the  intent  of 
selecting  the  optimum  design  based  upon  established  criteria,  is 
expected.  These  criteria  may  be  significantly  different  across  products, 
depending  on  product  type,  operational  environment,  performance 
requirements,  support  requirements,  and  cost  or  delivery  schedules. 

The  task  of  selecting  the  final  solution  makes  use  of  the  specific 
practices  in  the  Decision  Analysis  and  Resolution  process  area. 

[FM102.HDA104.HDB102.T1 14] 


The  Technical  Solution  process  area  relies  on  the  specific  practices  in 
the  Verification  process  area  to  perform  design  verification  and  peer 
reviews  during  design  and  prior  to  final  build,  [fmio2  hdaio4.hdbio2.th5] 


Overview 


69 


CMMI-SW,  vl.1 
Continuous  Representation 


The  Verification  process  area  ensures  that  selected  work  products  meet 
the  specified  requirements.  The  Verification  process  area  selects  work 
products  and  verification  methods  that  will  be  used  to  verify  work 
products  against  specified  requirements.  Verification  is  generally  an 
incremental  process,  starting  with  product-component  verification  and 
usually  concluding  with  verification  of  fully  assembled  products. 

[FM102.HDA104.HDB102.T1 16] 


Verification  also  addresses  peer  reviews.  Peer  reviews  are  a  proven 
method  for  removing  defects  early  and  provide  valuable  insight  into  the 
work  products  and  product  components  being  developed  and 
maintained,  [fmio2.hdaio4.hdbio2.th7] 

The  Validation  process  area  incrementally  validates  products  against 
the  customer’s  needs.  Validation  may  be  performed  in  the  operational 
environment  or  a  simulated  operational  environment.  Coordination  with 
the  customer  on  the  validation  requirements  is  one  of  the  most  essential 
elements  of  this  process  area,  [fmio2.hdaio4.hdbio2.th8] 

The  scope  of  the  Validation  process  area  includes  validation  of 
products,  product  components,  selected  intermediate  work  products, 
and  processes.  The  product,  product  component,  selected  intermediate 
work  product,  or  process  may  often  require  re-verification  and  re¬ 
validation.  Issues  discovered  during  validation  are  usually  resolved  in 
the  Requirements  Development  or  Technical  Solution  process  areas. 

[FM102.HDA104.HDB102.T1 19] 


The  Product  Integration  process  area  establishes  the  expected  specific 
practices  associated  with  generating  the  best  possible  integration 
sequence,  integrating  product  components  and  delivering  the  product  to 

the  customer.  [FMIO2.HDAIO4.HDBIO2.TI2O] 

Product  Integration  uses  the  specific  practices  of  both  Verification  and 
Validation  in  implementing  the  product  integration  process.  Verification 
verifies  the  interfaces  and  interface  requirements  between  product 
components  prior  to  product  integration.  This  is  an  essential  event  in 
the  integration  process.  During  product  integration  in  the  operational 
environment,  the  specific  practices  of  the  Validation  process  area  are 

USed.  [FM102.HDA104.HDB102.T121] 
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Engineering  Process  Areas  and  Recursion 

All  Engineering  process  areas  have  been  written  to  support  recursion 
throughout  the  product  architecture.  An  example  is  the  Establish 
Product  Integration  Procedures  and  Criteria  specific  practice  in  the 
Product  Integration  process  area.  For  a  product  with  many  complex 
product  components,  this  specific  practice  would  be  applied  to  the 
product  components  of  the  complete  product  delivered  to  the  customer 
as  well  as  to  the  product  components  assembled  to  form  the  product, 
and  so  on.  Thus,  this  specific  practice  is  applied  to  as  many  levels  as 
necessary  to  integrate  everything  that  the  product  comprises. 

[FM102.HDA104.HDB103.T101] 


There  is  no  specific  practice  that  forces  recursive  process  application. 
Rather,  the  specific  practices  are  written  in  a  fashion  that  “expects” 
process  application  throughout  the  product  architecture.  When 
implementing  the  specific  practices  of  an  Engineering  process  area,  you 
must  interpret  them  according  to  how  they  meet  the  needs  of  your 
product.  You  may  be  more  comfortable  viewing  this  approach  as 
providing  a  sufficiently  generic  set  of  expectations  that  can  be  applied  at 
any  level  of  product  detail  rather  than  as  enabling  recursive  behavior  of 
a  process.  Either  description  of  this  approach  is  appropriate. 

[FM1 02.HDA1 04.HDB1 03.T1 03] 


There  are  a  number  of  advantages  gained  by  this  approach.  For 
example,  the  Engineering  process  areas  can  be  applied  to  a  product 
that  has  several  layers  of  product  components  and  ensure  that  the 
specific  practices  will  address  each  layer.  Thus,  different  segments  of  a 
very  large  project  can  be  appraised  using  the  same  model. 

[FM1 02.HDA1 04.HDB1 03.T1 02] 


Support 


The  Scope  of  Support 

Support  process  areas  cover  the  activities  that  support  product 
development  and  maintenance.  The  Support  process  areas  address 
processes  that  are  used  in  the  context  of  performing  other  processes.  In 
general  the  Support  process  areas  address  processes  that  are  targeted 
towards  the  project,  and  may  address  processes  that  apply  more 
generally  to  the  organization.  For  example,  Process  and  Product 
Quality  Assurance  can  be  used  with  all  the  process  areas  to  provide  an 
objective  evaluation  of  the  processes  and  work  products  described  in  all 
of  the  process  areas,  [fmio2.hdaio5.hdbioi.tioi] 

Remember  to  focus  on  the  information  relevant  to  your  organization  and 
included  in  the  model  you  are  using,  [fmio2hdaios.hdbioi.tio4] 
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The  Support  process  areas  of  CMMI  are  as  follows:  [fmio2.hdaio5.hdbioi.tio6] 

•  Configuration  Management 

•  Process  and  Product  Quality  Assurance 

•  Measurement  and  Analysis 

•  Organizational  Environment  for  Integration 

•  Decision  Analysis  and  Resolution 

•  Causal  Analysis  and  Resolution 

To  describe  the  interactions  among  the  Support  process  areas,  it  is 
most  useful  to  address  them  in  two  process  area  groups: 

[FM102.HDA105.HDB101.T109] 

•  The  basic  Support  process  areas  are  Measurement  and  Analysis, 
Process  and  Product  Quality  Assurance,  and  Configuration 
Management. 

•  The  advanced  Support  process  areas  are  Organizational 
Environment  for  Integration,  Causal  Analysis  and  Resolution,  and 
Decision  Analysis  and  Resolution. 

Basic  Support  Process  Areas 

The  basic  Support  process  areas  address  basic  support  functions  that 
are  used  by  all  process  areas.  Although  all  Support  process  areas  rely 
on  the  other  process  areas  for  inputs,  the  basic  Support  process  areas 
provide  support  functions  that  are  covered  by  generic  practices. 

[FM102.HDA105.HDB102.T101] 


Figure  7  provides  a  bird’s-eye  view  of  the  interactions  among  the  basic 
Support  process  areas  and  with  all  other  process  areas.7 

[FM102.HDA105.HDB102.T102 


7  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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Figure  7;  Basic  Support  Process  Areas  [fmio2.hdaios.hdbio2.tio4] 

The  Measurement  and  Analysis  process  area  supports  all  process 
areas  by  providing  specific  practices  that  guide  projects  and 
organizations  in  aligning  measurement  needs  and  objectives  with  a 
measurement  approach  that  will  provide  objective  results.  These  results 
can  be  used  in  making  informed  decisions  and  taking  appropriate 
corrective  actions,  [fmio2.hdaios.hdbio2.tio5] 

The  Process  and  Product  Quality  Assurance  process  area  supports  all 
process  areas  by  providing  specific  practices  for  objectively  evaluating 
performed  processes,  work  products,  and  services  against  the 
applicable  process  descriptions,  standards,  and  procedures  and 
ensuring  that  any  issues  arising  from  these  reviews  are  addressed. 
Process  and  Product  Quality  Assurance  supports  the  delivery  of  high- 
quality  products  and  services  by  providing  the  project  staff  and  all  levels 
of  managers  with  appropriate  visibility  into,  and  feedback  on,  the 
processes  and  associated  work  products  throughout  the  life  of  the 

project.  [FM102.HDA105.HDB102.T106] 
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The  Configuration  Management  process  area  supports  all  process 
areas  by  establishing  and  maintaining  the  integrity  of  work  products 
using  configuration  identification,  configuration  control,  configuration 
status  accounting,  and  configuration  audits.  The  work  products  placed 
under  configuration  management  include  the  products  that  are 
delivered  to  the  customer,  designated  internal  work  products,  acquired 
products,  tools,  and  other  items  that  are  used  in  creating  and  describing 
these  work  products.  Examples  of  work  products  that  may  be  placed 
under  configuration  management  include  plans,  process  descriptions, 
requirements,  design  data,  drawings,  product  specifications,  code, 
compilers,  product  data  files,  and  product  technical  publications. 

[FM102.HDA105.HDB102.T107] 

Advanced  Support  Process  Areas 

The  advanced  Support  process  areas  provide  the  projects  and 
organization  with  an  advanced  support  capability.  Each  of  these 
process  areas  relies  on  specific  inputs  or  practices  from  other  process 

areas.  [FMIO2.HDAIO5.HDBIO3.TIOI] 


Figure  8  provides  a  bird’s-eye  view  of  the  interactions  among  the 
advanced  Support  process  areas  and  with  all  other  process  areas.8 

[FM102.HDA105.HDB103.T102 


Figure  8:  Advanced  Support  Process  Areas  [fmio2.hdaw5.hdbio3.tios] 


s  See  Appendix  B  for  a  complete  list  of  process  area  abbreviations. 
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Using  the  Causal  Analysis  and  Resolution  process  area,  the  project 
strives  to  understand  the  common  causes  of  variation  inherent  in 
processes  and  remove  them  from  the  project’s  processes,  as  well  as 
using  this  knowledge  to  continually  improve  the  organization’s 
processes.  Both  the  defined  processes  and  the  organization’s  set  of 
standard  processes  are  targets  of  these  improvement  activities. 

[FM102.HDA105.HDB103.T107] 


The  Decision  Analysis  and  Resolution  process  area  supports  all  the 
process  areas  by  providing  a  formal  evaluation  process  that  ensures 
that  alternatives  are  compared  and  the  best  one  is  selected  to 
accomplish  the  goals  of  the  process  areas,  [fmio2.hdaio5.hdbio3.tio8] 

The  following  paragraph  is  only  applicable  to  models  containing  IPPD. 

[FM102.HDA105.HDB103.T1 10] 


The  Organizational  Environment  for  Integration  process  area 
establishes  the  approach  and  environment  for  the  implementation  of 
IPPD.  The  environment  is  established  by  obtaining,  adapting,  or 
developing  processes  that  facilitate  effective  integrated  team  behavior 
as  well  as  stakeholder  communication  and  collaboration,  creating  the 
organization’s  shared  vision,  and  managing  people  to  promote 
integrative  behavior.  Specific  practices  in  the  Organizational 
Environment  for  Integration  process  area  promote  both  team  and 
individual  excellence  while  enabling  and  rewarding  integration  across  all 
business  and  technical  functions  in  the  execution  of  the  projects. 

[FM102.HDA105.HDB103.T1 11] 


Applying  Generic  Practices  to  Process  Areas 


Generic  practices  are  model  components  that  are  present  in  both  the 
staged  and  continuous  representations.  Likewise,  in  both 
representations,  a  generic  practice  is  applied  to  a  process  area  in  the 
same  way.  Think  of  generic  practices  as  reminders.  They  serve  the 
purpose  of  reminding  you  to  do  things  right,  and  are  expected  model 
components,  [fmio2.hdaio6.tioi] 

For  example,  when  you  are  achieving  the  specific  goals  of  the  Project 
Planning  process  area,  you  are  establishing  and  maintaining  a  plan  that 
defines  project  activities.  One  of  the  generic  practices  that  applies  to  the 
Project  Planning  process  area  is  “Establish  and  maintain  the  plan  for 
performing  the  project  planning  process.”  When  applied  to  this  process 
area,  this  generic  practice  ensures  that  you  planned  the  approach  you 
were  taking  to  create  the  plan  for  the  project,  [fmio2.hdaio6.tio2] 
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When  you  are  achieving  the  goals  of  the  Organizational  Training 
process  area,  you  are  developing  the  skills  and  knowledge  of  people  so 
they  can  perform  their  roles  effectively  and  efficiently.  One  of  the 
generic  practices  that  applies  to  the  Organizational  Training  process 
area  is  “Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  training  process.”  When  applied  to  this 
process  area,  this  generic  practice  ensures  that  you  planned  the 
approach  you  were  taking  to  developing  the  skills  and  knowledge  of 
people  in  the  organization,  [fmio2.hdaio6.tio4] 

The  generic  goals  and  practices  are  the  model  components  that  provide 
commitment  and  consistency  throughout  an  organization’s  processes 
and  activities.  Consistency  and  commitment  result  in  what  is  called 
“institutionalization.”  In  other  words,  the  best  practices  that  the  CMMI 
models  describe  are  anchored  in  the  very  existence  and  operation  of 
the  organization,  [fmio2.hdaio6.tios] 

In  the  continuous  representation,  generic  practices  appear  in  every 
process  area  under  the  five  generic  goals,  although  the  subpractices  of 
these  generic  practices  appear  only  in  Chapter  4.  The  name  “generic” 
reflects  the  fact  that  these  goals  and  practices  are  applied  to  every 
process  area  chosen  by  the  organization  for  its  process-improvement 

effOrtS.  [FM102.HDA106.T1 06] 

Process  Area  and  Generic  Practice  Interaction 

In  the  continuous  representation,  some  Process  Management  process 
areas  enable  the  application  of  most  capability  level  3  through  5  generic 
practices  to  particular  process  areas  (hereafter  called  the  “subject 
process  area”),  [fmio2.hdaio6.hdbioi.tioi] 

At  capability  level  3,  the  Establish  a  Defined  Process  generic  practice 
operates  on  a  description  of  an  organizational  standard  process 
covering  the  subject  process  area.  For  example,  establishing  a  defined 
process  for  configuration  management  in  the  context  of  a  particular 
project,  or  in  the  context  of  developing  and  maintaining  the 
organization’s  set  of  standard  processes,  requires  a  standard  process 
and  supporting  assets  for  performing  configuration  management.  While 
these  could  be  developed  for  configuration  management  independently 
of  those  for  other  process  areas,  this  is  usually  approached  through  a 
broader  based  effort  to  define  standard  processes  for  several  related 
processes  to  provide  better  visibility  and  control.  The  Organizational 
Process  Definition  process  area  provides  this  role,  [fmio2.hdaio6.hdbioi.tio2] 


Overview 


CMMI-SW,  vl.1 
Continuous  Representation 


Likewise,  the  Collect  Improvement  Information  generic  practice 
assumes  organizational  assets  contain  what  has  been  learned  and 
enables  sharing  learning  the  next  time  a  defined  process  that  covers 
the  subject  process  area  is  needed.  For  example,  a  defined  process  for 
configuration  management  generates  progress  and  baseline  accounting 
data  and  perhaps  process  artifacts  that  can  be  adapted  the  next  time 
configuration  management  needs  to  be  performed.  The  Organizational 
Process  Definition  process  area  again  provides  this  role. 

[FM102.HDA106.HDB101.T103] 


Therefore,  the  capability  level  3  generic  practices  are  “enabled”  by  the 
Organizational  Process  Definition  process  area,  [fmio2.hdaio6.hdbioi.tio4] 

The  Integrated  Project  Management  process  area  also  supports  the 
capability  level  3  generic  practices  when  they  are  applied  to  a  Project 
Management,  Engineering,  or  Support  process  area,  but  in  a  different 
way — it  performs  the  generic  practice  for  several  process  areas.  The 
Integrated  Project  Management  process  area  establishes  the  project’s 
defined  process,  which  integrates  defined  processes  covering  the  basic 
Project  Management,  Engineering,  and  Support  process  areas.  Thus,  if 
you  have  evolved  one  or  more  of  these  process  areas  to  capability  level 
3,  you  are  in  fact  accomplishing  a  significant  portion  of  the  first  specific 
goal  of  Integrated  Project  Management,  and  vice  versa. 

[FM1 02.HDA106.HDB1 01  ,T1 06] 


The  capability  level  3  generic  practices  subsume  part  of  the  Integrated 
Project  Management  process  area.  Even  if  all  basic  Project 
Management,  Engineering,  and  Support  process  areas  are  grown  to 
capability  level  3,  the  subsumption  is  not  complete — the  result  may  not 
be  an  integrated,  defined  process  for  the  project.  More  importantly,  the 
second  specific  goal  has  not  necessarily  been  addressed. 

[FM102.HDA106.HDB101.T108] 


This  “subsume  part  of”  relationship  is  important  to  remember  during 
appraisals,  as  observations  can  be  duplicated  between  the  generic 
practices  and  their  related  process  areas.  (The  actual  generation  of  the 
information  is  described  in  the  Integrated  Project  Management  process 
area  if  the  scope  of  the  process  area  falls  within  projects.) 

[FM102.HDA106.HDB101.T1 10] 


At  capability  level  4,  the  Establish  Quantitative  Objectives  for  the 
Process  generic  practice  assumes  and  benefits  from  an  organizational 
process  performance  analysis  that  typically,  though  not  necessarily, 
covers  several  related  processes  considered  critical  to  process 
performance.  Likewise,  the  Stabilize  Subprocess  Performance  generic 
practice  assumes  additional  supporting  assets  that  provide  insight  into 
the  expected  performance  of  critical  subprocesses  addressed  by  the 
subject  process  area.  The  Organizational  Process  Performance 
process  area  provides  both  roles,  [fmio2.hdaio6.hdbioi.tih] 
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At  capability  level  5,  the  Organizational  Innovation  and  Deployment 
process  area  actually  performs  the  Ensure  Continuous  Process 
Improvement  generic  practice  for  other  process  areas.  In  both  the 
generic  practice  and  the  process  area,  a  systematic  approach  is  taken 
to  identifying,  evaluating,  and  deploying  improvements  to  both 
processes  and  technologies  that  typically,  though  not  necessarily,  cover 
several  related  process  areas.  Thus,  the  Ensure  Continuous  Process 
Improvement  generic  practice  subsumes  part  of  the  Organizational 
Innovation  and  Deployment  process  area.  There  can  of  course  be 
considerable  benefit  in  taking  a  more  broad  and  integrated  approach  to 
organizational  innovation  and  deployment,  but  the  generic  practice 
helps  track  the  advancement  of  individual  process  areas  to  capability 

level  5.  [FM102.HDA106.HDB101.T112] 

Likewise,  the  Correct  Root  Causes  of  Problems  generic  practice 
subsumes  part  of  the  Causal  Analysis  and  Resolution  process  area. 
There  can  be  considerable  benefit  in  taking  a  broader  and  more 
integrated  approach  to  causal  analysis  and  resolution,  but  the  generic 
practice  helps  track  the  advancement  of  individual  process  areas  to 
capability  level  5.  [fmio2.hdaio6.hdbioi.th3] 

Given  the  above  dependencies,  to  raise  a  process  area  to  capability 
level  3,  it  would  be  natural  to  expect  (although  it  is  not  required)  that  the 
Organizational  Process  Focus  and  Organizational  Process  Definition 
process  areas  be  implemented.  Evolving  a  process  area  to  capability 
level  4  or  5  is  typically  achieved  by  implementing  at  least  some  parts  of 
those  process  areas,  as  illustrated  in  Table  1.  [fmio2.hdaio6hdbioi.tim] 


Generic  Practice 

Process  area  that  enables 
(or  is  subsumed  partly  by) 
the  generic  practice 

Both  capability  level  3 
generic  practices 

Enabled  by  Organizational  Process 
Definition 

Subsumes  part  of  Integrated  Project 
Management 

Both  capability  level  4 
generic  practices 

Enabled  by  Organizational  Process 
Performance 

Subsumes  part  of  Quantitative  Project 
Management 

Ensure  Continuous 

Process  Improvement 
generic  practice  (CL5) 

Enabled  by,  and  subsumes  part  of, 
Organizational  Innovation  and 

Deployment 

Correct  Root  Causes  of 
Problems  generic  practice 
(CL5) 

Subsumes  part  of  Causal  Analysis  and 
Resolution 

Table  1:  Generic  Practices  and  Related  Process  Areas 

[FM102.HDA106.HDB1 01.  Til  6] 
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There  are  also  a  few  of  what  may  seem  like  overlaps,  but  are  not.  It 
may  be  natural  to  think  that  the  application  of  the  Establish  a  Defined 
Process  generic  practice  applied  to  the  Project  Planning  and  Project 
Monitoring  and  Control  process  area  gives  the  same  effect  as  the  first 
specific  goal  of  Integrated  Project  Management,  [fmio2.hdaio6.hdbioi.th9] 

Although  it  is  true  that  there  is  some  overlap,  the  application  of  the 
generic  practice  to  these  two  process  areas  provides  defined  processes 
covering  project  planning  and  monitoring  activities.  These  defined 
processes  do  not  cover  support  activities  (such  as  configuration 
management),  other  Project  Management  process  areas  (such  as 
Supplier  Agreement  Management),  or  the  Engineering  process  areas. 

In  contrast,  the  project’s  defined  process,  provided  by  the  Integrated 
Project  Management  process  area,  covers  all  basic  Project 
Management,  Engineering,  and  Support  process  areas. 

[FM102.HDA106.HDB101.T121] 


Account  for  these  overlaps  when  you  are  conducting  appraisals  or 
planning  improvements  using  the  continuous  representation. 

[FM1 02.HDA106.HDB1 01  ,T1 22] 

Overlap  of  Generic  Practices  and  Process  Management  Process 
Areas 

As  indicated  in  Table  1,  there  are  overlaps  between  some  Process 
Management  process  areas  and  some  generic  practices. 

[FM102.HDA106.HDB102.T101] 


To  raise  a  targeted  set  of  process  areas  to  capability  levels  3,  4,  or  5,  it 
is  necessary  to  implement  both  the  generic  practices  and  the  enabling 
process  areas  in  a  way  that  covers  the  targeted  set  of  process  areas. 
When  doing  this,  there  is  some  advantage  to  implementing  the  process 
areas  the  generic  practices  partially  subsume,  because  of  the  broader 
view  they  provide.  Remember  that  when  you  implement  one  of  these 
partially  subsumed  process  areas,  you  are  applying  its  corresponding 
generic  practices  across  a  large  number  of  process  areas,  and  thus 
there  is  an  intended  overlap,  [fmio2.hdaio6.hdbio2.tio2] 
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6  Using  CMMI  Models 


The  CMMI  project  has  worked  to  preserve  the  government  and  industry 
investments  in  process  improvement  and  to  enhance  and  replace  the 
use  of  multiple  models.  In  addition  to  improving  the  usability  of  CMM 
technology  in  a  wider  set  of  disciplines,  the  CMMI  concept  calls  for  use 
of  common  terminology,  common  components,  common  appraisal 
methods,  and  common  training  materials  across  the  CMMI  Product 
Suite.  The  objective  of  the  CMMI  project  effort  is  to  reduce  the  cost  of 
establishing  and  maintaining  process-improvement  efforts  across  an 
enterprise  using  multiple  disciplines  to  produce  products  or  services. 
This  chapter  describes  how  organizations  can  use  CMMI  models  for 
both  process  improvement  and  benchmarking.  [FM120.T101] 


Interpreting  CMMI  Models 


Every  CMMI  model  provides  a  set  of  publicly  available  criteria 
describing  the  characteristics  of  organizations  that  have  successfully 
implemented  process  improvement.  These  criteria  can  be  used  by 
organizations  to  improve  their  processes  for  developing,  acquiring,  and 
maintaining  products  and  services.  While  a  new  enterprise  might  wish 
to  establish  its  processes  using  these  concepts,  the  models  are  more 
commonly  of  interest  to  organizations  that  are  seeking  to  improve  their 
processes,  [fmi20.hdaioi.tioi] 


Such  organizations  must  use  professional  judgment  to  interpret  CMMI 
practices.  Although  process  areas  depict  behavior  that  should  be 
exhibited  in  any  organization,  practices  must  be  interpreted  using  an  in- 
depth  knowledge  of  the  CMMI  model  being  used,  the  organization,  the 
business  environment,  and  the  specific  circumstances  involved. 

[FM120.HDA101.T102] 


CMMI  practices  purposely  use  nonspecific  phrases  such  as  “relevant 
stakeholders,”  “as  appropriate,”  and  “as  necessary”  to  accommodate 
the  needs  of  different  organizations  or  projects.  Specific  needs  may 
also  differ  at  various  points  during  a  project’s  life,  [fmi2o.hdaioi.tio3] 
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To  interpret  practices,  it  is  important  to  consider  the  overall  context  in 
which  they  are  used  and  determine  how  well  the  practices  satisfy  the 
goals  of  a  process  area  within  that  context.  CMMI  models  do  not  imply 
which  processes  are  right  for  the  organization  or  project.  Instead,  CMMI 
models  establish  minimal  criteria  necessary  to  plan  and  implement 
processes  selected  by  the  organization  for  improvement  based  on 
business  objectives,  [fmi2o.hdaioi.tio4] 


Appraisals  and  Benchmarking 


Process  appraisals  focus  on  identifying  improvement  opportunities.  The 
organization  should  set  its  priorities  based  on  its  business  and  process- 
improvement  objectives,  as  well  as  its  collection  of  business  and 
technical  processes.  Appraisal  teams  use  CMMI  models  to  guide  them 
in  identifying  and  prioritizing  findings.  These  findings,  with  guidance 
provided  by  the  practices  in  the  CMMI  models,  are  used  (by  a  process 
group,  for  example)  to  plan  improvements  for  the  organization.  In 
addition,  many  organizations  find  value  in  benchmarking  their  progress 
in  process  improvement  for  both  internal  purposes  and  with  external 
customers  and  suppliers,  [fmi2o.hdaio2.tioi] 

For  organizations  that  wish  to  appraise  multiple  disciplines,  the 
integrated  CMMI  approach  permits  some  economy  of  scale  in  model 
and  appraisal  training.  One  appraisal  method  can  provide  separate  or 
combined  results  for  multiple  disciplines.  [FMi20.HDAi02.Ti02] 

CMMI  appraisal  products  provide  consistent  ratings  for  staged  and 
continuous  representations.  Equivalent  staging  enables  organizations 
using  a  continuous  representation  to  convert  their  appraisal  ratings  into 
a  maturity  level,  [fmi2o.hdaio2.tio5] 

The  appraisal  principles  for  the  CMMI  Product  Suite  remain  the  same 
as  those  used  in  past  appraisals  using  many  other  process- 
improvement  models.  Those  principles  are:  [fmi2o.hdaio2.tio6] 

•  Senior-management  sponsorship 

•  A  focus  on  the  organization’s  business  objectives 

•  Confidentiality  for  interviewees 

•  Use  of  a  documented  appraisal  method 

•  Use  of  a  process  reference  model  (for  example,  a  CMMI  model)  as 
a  base 

•  A  collaborative  team  approach 

•  A  focus  on  actions  for  process  improvement 
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Over  time,  a  suite  of  appraisal  techniques  is  expected  to  be  developed 
by  CMMI  user-community  members.  New  techniques  will  be  developed 
and  existing  ones  improved  to  meet  various  needs  for  building  internal 
improvement.  The  CMMI  project  has  produced  one  method  to  meet  the 
need  for  a  rigorous  appraisal  tool  for  benchmarking  and  a  set  of 
guidelines  for  future  process-improvement  appraisals  requiring  less 
rigor  and  repeatability.  This  most  rigorous  version  has  been  named  the 
Standard  CMMI  Appraisal  Method  for  Process  Improvement 
(SCAMPIsm).  Details  on  this  method  are  available  on  the  Software 
Engineering  Institute  Web  site  at  the  following  URL: 
<http://www.sei.cmu.edu/cmmi/products/assess.html>.  [fmi2o.hdaio2.tio7 

For  benchmarking  against  other  organizations,  appraisals  must  ensure 
consistent  ratings.  The  achievement  of  a  specific  maturity  level  or  the 
satisfaction  of  a  process  area  must  mean  the  same  thing  for  different 
appraised  organizations.  Rules  for  ensuring  this  consistency  are 
provided  in  the  document  mentioned  above.  SCAMPI  is  the  only 
appraisal  method  initially  considered  to  be  suitable  for  rendering  ratings 
for  benchmarking  using  CMMI  models.  The  SEI,  as  steward  of  the 
CMMI  Product  Suite,  will  ensure  that  any  public  comments  or 
statements  about  maturity  levels  or  ratings  resulting  from  a  SCAMPI 
appraisal  meet  quality  and  consistency  criteria,  [fmi2o.hdaio2.tio8] 

SCAMPI  was  written  to  support  the  conduct  of  appraisals  that  conform 
to  the  emerging  International  Organization  for  Standardization  and  the 
International/Electrotechnical  Commission  (ISO/I EC)  15504  technical 
report.  However,  it  is  possible  that  a  SCAMPI  appraisal  might  not  be 
15504  conformant.  ISO/IEC  15504  is  an  international  collaboration  to 
develop  a  standard  set  of  technical  reports  on  software  process 
assessment  that  has  been  underway  since  June  1 993  under  the 
auspices  of  the  ISO/IEC.  For  those  sponsors  interested  in  performing 
an  ISO/IEC  15504-conformant  appraisal,  SCAMPI  can  support  these 

needs.  [FMi20.HDAi02.Ti09] 

Appraisal  Requirements  for  CMMI 

The  Appraisal  Requirements  for  CMMI  (ARC)  document  contains  a  set 
of  criteria  for  developing,  defining,  and  using  appraisal  methods  based 
on  CMMI  products.  The  ARC  provides  requirements  for  multiple  types 
of  appraisal  methods  with  guidelines  for  determining  the  suitability  of  a 
particular  appraisal  method.  Suitability  addresses  the  accuracy  and 
repeatability  of  appraisal  results,  [fmi2o.hdaio2.hdbioi.tioi] 


SM  SCAMPI  is  a  service  mark  of  Carnegie  Mellon  University. 
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The  ARC  document  uses  the  CMMI  models  as  its  associated  reference 
models.  The  CMM  Appraisal  Framework  (CAF)  vl  .0  was  originally 
produced  to  address  appraisal  methods  associated  with  the  CMM  for 
Software  only.  With  the  incorporation  of  CMMs  into  the  CMMI 
Framework,  the  ARC  has  been  created  to  address  these  new  models 
and  the  resulting  impact  of  the  staged  and  continuous  representations. 

[FM120.HDA102.HDB101.T102] 


The  ARC  document  was  designed  to  help  improve  consistency  across 
multiple  disciplines  and  appraisal  methods,  and  to  help  appraisal 
method  developers,  sponsors,  and  users  understand  the  tradeoffs 
associated  with  various  methods.  More  information  and  a  matrix 
detailing  ARC  requirements  are  available  on  the  Software  Engineering 
Institute’s  Web  site,  [fmi2o.hdaio2.hdbioi.tio3] 

Other  CMMI-based  appraisal  methods  may  be  appropriate  for  a  given 
set  of  sponsor  needs,  including  self  assessments,  initial  appraisals, 
quick-look  or  mini  appraisals,  incremental  appraisals,  and  external 
appraisals.  Method  developers  are  expected  and  encouraged  to 
develop  a  variety  of  appraisal  methods  to  meet  these  needs. 

[FM120.HDA102.HDB101.T104] 

ISO/IEC  15504  Compatibility  and  Conformance 

One  objective  that  the  CMMI  Product  Suite  was  designed  to  achieve  is 
that  of  ISO/IEC  15504  compatibility  and  conformance.  There  are  two 
aspects  of  conformance  to  the  1998  Technical  Report  version  of 
ISO/IEC  15504:  model  compatibility  and  appraisal  conformance.  When 
the  full  international  standard  version  of  ISO/IEC  15504  is  published 
(estimated  to  occur  in  2003),  there  will  be  some  changes  to  what 
ISO/IEC  15504  conformance  means,  [fmi2ohdaio2.hdbio2.tioi] 

For  an  appraisal  model  (for  example,  Bootstrap,  CMMI-SE/SW,  and  so 
on)  to  claim  to  be  ISO/IEC  15504  conformant  (an  ISO/IEC  15504- 
compatible  model),  a  “demonstration  of  compatibility”  document  would 
need  to  show  how  the  model  compatibility  requirements  of  ISO/IEC 
15504-2  have  been  addressed.  These  requirements  are  constructed  to 
provide  reasonable  assurance  that  the  model  will  work  properly  with  the 
associated  documented  appraisal  process  (appraisal  method). 

[FM120.HDA102.HDB102.T102] 


There  are  also  ISO/IEC  15504  requirements  that  pertain  to  the  actual 
conduct  (planning  as  well  as  performance)  of  an  appraisal.  If  the 
conduct  of  an  appraisal  is  such  that  the  requirements  in  ISO/IEC  15504- 
3  are  satisfied,  then  the  appraisal  is  said  to  be  ISO/IEC  15504 
conformant.  One  of  these  requirements  is  that  a  ISO/IEC  15504- 
compatible  appraisal  model  is  used,  [fmi2o  hdaio2.hdbio2.tio3] 
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Making  the  Transition  to  CMMI 


This  section  briefly  describes  three  transition  scenarios.  The  first  two 
assume  the  organization  has  already  begun  its  improvement  efforts 
using  either  the  Software  CMM  or  the  Electronic  Industries  Alliance 
Interim  Standard  (EIA/IS)  731.  The  third  scenario  assumes  that  the 
organization  has  not  used  a  particular  reference  model  for  current 
improvement  efforts,  or  that  there  have  been  no  improvement  efforts  to 

date.  [FM120.HDA103.T101] 

Organizations  with  Software  CMM  Experience 

Many  organizations  initially  making  the  transition  to  CMMI  will  likely  be 
seeking  to  update  their  process-improvement  efforts  to  incorporate  the 
Version  2.0  draft  C  improvements  and  to  gain  the  additional  breadth  of 
coverage  afforded  in  CMMI  models.  Many  of  these  organizations  will 
need  to  decide  the  best  timing  for  transition  to  preserve  the  value  of 
plans  toward,  for  example,  achievement  of  a  particular  maturity  level. 

[FM120.HDA103.HDB102.T101] 


Organizations  that  have  already  achieved  a  high  level  of  maturity  may 
wish  to  make  the  transition  more  quickly  to  take  advantage  of  the 
additional  organizational  coverage  described  in  CMMI  models.  These 
organizations  will  find  strong  commonality  between  CMMI  models  and 
the  Software  CMM.  Also,  there  is  significant  improvement  in  coverage 
of  the  engineering,  risk  management,  and  measurement  and  analysis 
processes,  as  compared  to  the  Software  CMM.  [fmi2o.hdaio3hdbio2.tio2] 

The  Software  CMM  practices  at  maturity  levels  4  and  5  have  been 
improved  based  on  experience  gained  since  the  publication  of  SW- 
CMM  Version  2  draft  C.  These  practices  have  been  further  refined  from 
the  source  model  based  on  studies  conducted  by  the  SEI  that  analyzed 
the  implementation  of  maturity  level  4  and  5  practices  by  leading 
organizations,  [fmi2o.hdaio3.hdbio2.tio3] 

Organizations  that  have  begun  significant  effort  toward  a  maturity  level 
2,  3,  or  4  appraisal  must  weigh  the  costs  of  making  the  transition 
against  the  benefits  of  the  improved  coverage  an  integrated  model 

Offers.  [FM120.HDA103.HDB102.T104] 

Organizations  may  wish  to  consider  the  versatility  offered  by  the 
continuous  and  staged  representations  in  planning  their  long-term 
appraisal  and  improvement  approaches.  If  the  costs  of  total  transition 
appear  high,  an  interim  approach  might  be  to  augment  their  current  plan 
with  selected  process  areas  that  would  be  of  greatest  business  value. 

[FM120.HDA103.HDB102.T105] 
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For  example,  a  company  with  several  months  remaining  before  a 
maturity  level  4  appraisal  might  want  to  charter  small  teams  to 
investigate  Risk  Management  and  Measurement  and  Analysis,  and  add 
them  to  the  appraisal  scope  to  begin  the  transition  without  affecting 
current  efforts.  This  long-term  improvement  approach  allows  members 
of  the  organization  to  have  a  “first  look”  at  new  process  areas  and  to 
gain  insight  that  helps  them  build  business  value  in  these  two  process 
areas  as  well  as  preparing  them  for  future  CMMI  appraisals. 

[FM120.HDA103.HDB102.T106] 

Organizations  with  EIA/IS  731  Experience 

Organizations  that  have  framed  their  process-improvement  efforts 
around  systems-engineering  models  have  similar  choices  to  make, 
depending  upon  their  progress  on  current  improvement  efforts. 

[FM120.HDA103.HDB107.T101] 


The  evolution  from  Electronic  Industries  Alliance  Interim  Standard 
(EIA/IS)  731  involves  (1)  some  reorganization  of  specific  practices 
under  specific  goals  and  process  areas  and  (2)  the  addition  of 
informative  material.  Initial  transition  steps  therefore  might  be  to 
compare  current  improvement  efforts  against  those  now  expected  in  the 

CMMI  models.  [FM120.HDA103.HDB107.T1 02] 

Organizations  New  to  CMM-Type  Models 

Organizations  without  experience  in  either  SW-CMM  or  EIA/IS  731  are 
assumed  to  be  in  one  of  two  categories.  They  may  have  undertaken 
process-improvement  efforts  under  other  quality  initiatives  such  as  ISO 
9000  or  Malcolm  Baldrige,  or  they  may  be  considering  such  efforts 
because  of  the  mounting  evidence  of  business  value  resulting  from 
such  a  commitment,  [fmi2o.hdaio3.hdbio4.tioi] 

Both  categories  of  organizations  will  find  familiar  relationships  to  other 
quality  efforts  in  the  CMMI  Product  Suite.  They  also  gain  reference 
models  of  effective  practices  that  can  be  applied — across  the  value 
chain — to  enhance  the  quality  of  products  and  their  associated 

processes.  [FM120.HDA103.HDB104.T102] 


These  organizations  may  approach  improvement  by  using  either  a 
continuous  or  staged  representation.  Each  approach  is  complementary 
to  the  other.  Neither  is  mutually  exclusive,  but  the  choice  will  affect  the 
schedule  and  needs  of  the  organization  for  training  and  appraisal.  See 
the  Model  Representation  Comparison  section  in  Chapter  2  for  more 
information  about  selecting  a  CMMI  model  representation. 

[FM120.HDA103.HDB104.T103] 


86 


Overview 


CMMI-SW,  vl.1 
Continuous  Representation 


Once  your  organization  has  decided  which  representation  is  the  best  fit, 
planning  can  begin  with  an  improvement  approach  such  as  the 
Initiating,  Diagnosing,  Establishing,  Acting,  Learning  (IDEALSM)  model. 
(For  more  information  about  the  IDEAL  model,  see  the  Web  site 
<http://www.sei.cmu.edu/ideal/ideal.html>.)  Research  has  shown  that 
the  most  powerful  initial  step  to  process  improvement  is  to  build  strong 
organizational  sponsorship  during  the  Initiating  phase  prior  to  investing 
in  significant  diagnostic  efforts,  [fmi2o.hdaio3hdbio4.tio4 

Given  sufficient  senior-management  sponsorship,  establishing  a 
specific,  technically  competent  process  group  to  guide  process- 
improvement  efforts  has  proven  to  be  a  best  practice.  For  an 
organization  whose  mission  is  to  develop  software-intensive  systems, 
the  group  might  include  systems  engineers  and  software  engineers 
from  projects  across  the  organization,  and  other  selected  members 
based  on  the  business  needs  driving  improvement.  For  example,  a 
systems  administrator  may  focus  on  information-technology  support, 
whereas  a  marketing  representative  may  focus  on  integrating  customer 
needs.  Both  members  could  make  powerful  additions  to  the  process 

group.  [FM120.HDA103.HDB104.T105] 

Training 

Training  is  a  key  element  in  the  ability  of  organizations  to  adopt  CMMI 
and  is  therefore  a  key  part  of  the  product  suite.  While  an  initial  set  of 
courses  is  provided  by  the  SEI  and  its  transition  partners,  your 
organization  may  wish  to  supplement  these  courses  with  internal 
instruction.  This  approach  allows  the  organization  to  focus  on  the  areas 
that  provide  the  greatest  business  value,  [fmi2o.hdaio3.hdbio5.tioi] 

Initial  training  is  available  for  both  representations  of  CMMI  models. 
Training  is  also  provided  to  assist  those  who  plan  to  guide  improvement 
as  part  of  a  process  group,  or  those  seeking  to  become  lead  appraisers. 

[FM1 20.HDA103.HDB1 05.T1 02] 


Tailoring  Perspectives 


Tailoring  a  CMMI  model  is  a  process  whereby  only  a  subset  of  a  model 
is  used  to  suit  the  needs  of  a  specific  domain  of  application. 

[FM120.HDA105.T101] 


SM  IDEAL  is  a  service  mark  of  Carnegie  Mellon  University. 


Overview 


87 


CMMI-SW,  vl.1 
Continuous  Representation 


Tailoring  the  CMMI  appraisal  method  involves  the  selection  of  options 
for  use  in  an  appraisal.  In  both  cases,  the  intent  of  tailoring  is  to  assist 
an  organization  or  project  in  aligning  the  CMMI  products  with  its 
business  needs  and  objectives,  and  thus  focusing  on  those  aspects  of 
the  products  and  services  that  are  most  beneficial  to  the  organization. 

[FM120.HDA105.T102] 


The  tailoring  discussed  in  this  section  does  not  address  adaptation  of 
an  organization’s  set  of  standard  processes  for  use  on  a  specific 
project.  Such  tailoring  is  driven  by  tailoring  guidelines  defined  by  an 
organization,  [fmi2o.hdaio5.tio3] 


Model  Tailoring 


Model  tailoring  should  only  be  done  knowing  that  it  can  result  in 
significant  gaps  in  efforts  to  improve  or  appraise  an  organization’s  or  a 
project’s  capabilities,  [fmi2o.hdaio4.tioi] 

Model  Tailoring  Perspectives 

Tailoring  of  a  CMMI  model  can  be  viewed  from  two  perspectives: 

[FM120.HDA104.HDB101.T101] 

•  Model  tailoring  related  to  use  of  a  model  for  process  improvement 

•  Model  tailoring  related  to  use  of  a  model  for  benchmarking 

Many  organizations  will  use  a  CMMI  model  for  benchmarking  as  well  as 
process  improvement.  Such  tailoring  is  constrained  by  the  intersection 
of  criteria  outlined  in  the  next  two  sections,  [fmi2o.hdaio4  hdbioi.tio2] 

Model  Tailoring  Criteria  for  Internal  Process  Improvement 

For  internal  process  improvement,  it  is  appropriate  to  restrict  or  expand 
the  scope  of  an  organization’s  or  project’s  improvement  effort  (including 
appraisals).  The  tailoring  may  address  individual  disciplines,  process 
areas,  maturity  levels,  and/or  capability  levels.  Tailoring  of  a  model 
should  focus  on  identifying  the  process  areas  and  practices  that  support 
an  organization’s  business  needs  and  objectives,  [fmi2o  hdaio4.hdbio2.tioi] 
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Care  must  be  taken  when  considering  whether  to  exclude  portions  of  a 
CMMI  model.  Given  a  CMMI  model’s  focus  on  the  essential 
characteristics  of  an  effective  process,  the  majority  of  the  process  areas 
and  practices  in  a  model  typically  would  be  addressed.  In  fact,  the 
wholesale  exclusion  of  fundamental  processes  or  specific  practices  is 
discouraged,  given  the  prevalence  of  data  indicating  that  following 
CMM-based  improvement  efforts  will  significantly  improve  attainment  of 
business  objectives.  Cited  improvements  in  the  literature  include  the 
increased  likelihood  that  an  organization  or  project  will  achieve  its  cost 
and  schedule  objectives,  [fmi2o.hdaio4.hdbio2.tio2] 

Organizations  and  projects  implementing  less  than  a  full  set  of  process 
areas,  goals,  or  practices  can  still  achieve  significant  value  from  a 
CMMI  model.  However,  because  of  the  interrelationship  of  model 
components,  exclusion  of  a  significant  number  of  process  areas,  goals, 
or  practices  may  diminish  the  benefits  achieved.  In  addition,  the  degree 
of  comparability  of  appraisal  results  is  directly  related  to  the  extent  to 
which  a  model  and  appraisal  method  have  been  tailored. 

[FM120.HDA104.HDB102.T103] 

Model  Tailoring  Criteria  for  Benchmarking 

Use  of  CMMI  models  for  benchmarking  purposes  allows  for  comparison 
of  process  appraisal  results  across  an  industry  via  state-of-the-practice 
reports  or  across  a  group  of  organizations  such  as  potential  suppliers. 
Any  tailoring  applied  in  this  way  must  ensure  consistency  in  the  ratings 
resulting  from  the  use  of  models  in  multiple  appraisals.  As  a  result, 
model  tailoring  for  benchmarking  is  significantly  constrained,  especially 
where  maturity  levels  resulting  from  appraisals  are  disseminated 
publicly  for  marketing  purposes,  [fmi2o.hdaio4.hdbio3.tioi] 

Keep  in  mind  that  the  scope  chosen  for  an  appraisal  also  affects  the 
context  of  benchmarking.  If  one  organization  chooses  to  appraise  only 
software  engineering  while  another  chooses  to  appraise  software  and 
systems  engineering,  comparing  the  two  would  not  be  fair  or  accurate. 
Model  tailoring  criteria  for  benchmarking  are  defined  as  follows: 

[FM120.HDA104.HDB103.T102] 

•  Process  areas  include  required  and  expected  model  components 
and  thus  may  not  be  excluded  other  than  to  omit  those  that  are 
outside  the  scope  of  an  appraisal.  For  example,  when  an 
organization  uses  a  staged  representation,  process  areas  at 
maturity  levels  4  and  5  may  be  omitted  for  an  appraisal  focused  on 
maturity  level  3,  whereas  all  process  areas  for  maturity  levels  2  and 
3  would  typically  be  selected.  When  using  a  continuous 
representation,  process  areas  outside  the  scope  of  the  target 
profile  may  be  omitted,  but  doing  so  will  compromise  the 
benchmarking  opportunities  provided  by  equivalent  staging. 
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•  Process  areas,  in  some  circumstances,  may  be  determined  to  be 
“not  applicable”  if  the  process  area  is,  in  fact,  outside  of  the 
organization’s  scope  of  work.  An  example  of  a  process  area  that 
might  be  excluded  from  an  appraisal  using  a  staged  representation 
would  be  Supplier  Agreement  Management,  a  process  area  that 
may  not  be  applicable  in  the  absence  of  suppliers  of  products  and 
services  external  to  the  organization  that  are  critical  to  the 
development  effort.  A  maturity  level  rating  could  still  be  determined; 
however,  that  maturity  level  rating  must  also  include  mention  of  the 
“not  applicable”  process  area.  Conversely,  when  using  a 
continuous  representation,  process  areas  may  be  selected  for 
exclusion  if  they  are  not  within  the  organization’s  scope  of  work  or 
of  the  process-improvement  effort.  Care  must  be  taken,  however, 
that  process  areas  providing  the  foundation  for  other  process  areas 
important  to  the  organization  are  not  excluded.  Furthermore,  even 
though  an  organization  uses  a  continuous  representation,  if  it 
wishes  to  use  equivalent  staging  it  must  adhere  to  the  tailoring 
guidelines  practiced  by  users  of  the  staged  representation. 

•  A  process  area  is  designated  as  “not  rated”  if  it  is  outside  the 
appraisal  scope  or  if  insufficient  data  is  available  to  satisfy  the 
data-coverage  criteria.  A  maturity  level  cannot  be  determined  if 
process  areas  at  that  maturity  level  (or  below)  are  “not  rated.” 

•  Goals  are  required  and  thus  cannot  be  excluded  from  those 
process  areas  included  in  the  scope  of  a  process-improvement  or 
appraisal  effort.  Goals  reflect  the  minimum  requirements  for 
satisfying  a  process  area.  If  a  process  area  is  applicable,  each  of 
its  goals  is  applicable.  Goals  work  together  to  support  a  process 
area  and  may  not  be  individually  designated  as  “not  applicable.” 

•  Specific  practices  and  generic  practices  are  expected  to  be 
implemented  as  typical  activities  necessary  to  implement  and 
institutionalize  the  goals  of  the  process  area.  However,  appropriate 
alternative  practices  may  be  substituted  for  specific  practices 
and/or  generic  practices  if  the  alternatives  are  effective  in 
implementing  and  institutionalizing  the  goals. 

•  All  other  model  components  (subpractices,  examples, 
amplifications,  elaborations,  and/or  references)  contained  in  CMMI 
models  are  informative  and  are  provided  solely  for  guidance  in 
implementation. 

Model  Tailoring  for  Smaller  Projects 

The  CMMI  models  were  written  for  use  by  all  types  of  organizations; 
however,  for  small  organizations  a  CMMI  model  must  be  interpreted.  In 
the  case  of  small,  three-  to  six-month  projects,  a  high-level  plan  is 
typically  available  that  has  been  developed  for  a  group  of  projects.  This 
high-level  plan  defines  the  organization,  resources,  training, 
management  participation,  and  quality  assurance  reporting  descriptions 

for  all  projects.  [FM120.HDA104.HDB104.T101] 


Overview 


CMMI-SW,  vl.1 
Continuous  Representation 


Conversely,  in  the  project  plan,  the  detailed  planning  of  the  project, 
such  as  the  schedule,  tasks,  and  resources,  are  defined.  Often  the 
project  plan  also  contains  plans  for  other  supporting  functions,  such  as 
quality  assurance  and  configuration  management.  A  four-person  project 
might  expect  to  develop  a  project  plan  that  is  only  a  few  pages  long. 

[FM1 20.HDA1 04.HDB1 04.T1 02] 


In  small  projects,  meetings  take  place  more  frequently,  take  less  time, 
and  cover  more  details.  The  schedule  may  contain  daily  activities,  and 
may  be  monitored  in  weekly  meetings.  The  schedule  may  change 
weekly  and  be  controlled,  [fmi2o.hdaio4.hdbio4.tio4] 

In  a  small  team,  the  customer  usually  knows  the  entire  team  and  feels 
comfortable  calling  any  member  of  the  team  to  propose  or  discuss  a 
change.  The  team  must  decide  up  front  how  to  handle  these  informal 
calls  from  the  customer.  Once  team  members  have  decided  on  an 
approach,  it  should  be  documented  and  communicated  to  the  customer. 

[FM1 20.HDA1 04.HDB1 04.T1 05] 

Appraisal  Tailoring 

The  major  appraisal-tailoring  options  for  a  CMMI  appraisal  include  the 

following:  [FM120.HDA104.HDB105.T101] 

•  Establishing  the  appraisal  scope,  including  the  organizational  entity 
to  be  appraised,  the  CMMI  process  areas  to  be  investigated,  and 
the  level  to  be  appraised 

•  Selecting  the  appraisal  method 

•  Selecting  the  appraisal  team  members 

•  Selecting  appraisal  participants  from  the  appraisal  entity  to  be 
interviewed 

•  Establishing  appraisal  outputs  (for  example,  ratings,  instantiation- 
specific  findings) 

•  Establishing  appraisal  constraints  (for  example,  time  spent  on  site) 

In  addition  to  these  appraisal-tailoring  options,  the  CMMI  appraisal 
method  description  details  a  number  of  specific  appraisal-tailoring 
options  driven  by  considering  the  objectives  of  a  particular  appraisal 
and  the  business  objectives  of  the  organization  and/or  instantiation. 
Documentation  of  CMMI  appraisal  plans  and  results  must  always 
include  a  description  of  the  appraisal-tailoring  options  selected,  as  well 
as  any  model  tailoring.  Such  documentation  will  enable  a  determination 
to  be  made  of  the  comparability  of  appraisal  results  across 
organizations,  [fmi2o.hdaio4.hdbio5.tio2] 
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PROCESS  MANAGEMENT 


The  following  section  contains  all  of  the  process  areas  that  belong  to 
the  Process  Management  process  area  category.  The  process 
Management  process  areas  of  CMMI  are  as  follows:  [fmkm.tioij 

•  Organizational  Process  Focus 

•  Organizational  Process  Definition 

•  Organizational  Training 

•  Organizational  Process  Performance 

•  Organizational  Innovation  and  Deployment 

See  Chapter  5  for  more  information  about  the  Process  Management 
process  areas  and  how  they  interact.  [fmkm.tkk] 
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ORGANIZATIONAL  PROCESS  FOCUS 

Process  Management 


Purpose 


The  purpose  of  Organizational  Process  Focus  is  to  plan  and  implement 
organizational  process  improvement  based  on  a  thorough 
understanding  of  the  current  strengths  and  weaknesses  of  the 
organization’s  processes  and  process  assets.  [PA152] 


Introductory  Notes 


The  organization's  processes  include  the  organization's  set  of  standard 
processes  and  the  defined  processes  that  are  tailored  from  them.  The 
organizational  process  assets  are  used  to  establish,  maintain, 
implement,  and  improve  the  defined  processes.  See  Chapter  3  for  an 
explanation  of  how  “organizational  process  assets”  is  used  in  the  CMMI 
Product  Suite.  [pais2.nioi] 

Candidate  improvements  to  the  organizational  process  assets  are 
obtained  from  various  sources,  including  measurement  of  the 
processes,  lessons  learned  in  implementing  the  processes,  results  of 
process  appraisals,  results  of  product  evaluation  activities,  results  of 
benchmarking  against  other  organizations'  processes,  and 
recommendations  from  other  improvement  initiatives  in  the 
organization.  [PA152N102] 

Process  improvement  occurs  within  the  context  of  the  organization’s 
needs  and  is  used  to  address  the  organization's  objectives.  The 
organization  encourages  participation  in  process-improvement  activities 
by  those  who  will  perform  the  process.  The  responsibility  for  facilitating 
and  managing  the  organization's  process-improvement  activities, 
including  coordinating  the  participation  of  others,  is  typically  assigned  to 
a  process  group.  The  organization  provides  the  long-term  commitment 
and  resources  required  to  sponsor  this  group.  [pais2.nio3] 
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Careful  planning  is  required  to  ensure  that  process-improvement  efforts 
across  the  organization  are  adequately  managed  and  implemented. 

The  organization’s  planning  for  process-improvement  results  in  a 
process-improvement  plan.  The  organization’s  process-improvement 
plan  will  address  appraisal  planning,  process  action  planning,  pilot 
planning,  and  deployment  planning.  Appraisal  plans  describe  the 
appraisal  timeline  and  schedule,  the  scope  of  the  appraisal,  the 
resources  required  to  perform  the  appraisal,  the  reference  model 
against  which  the  appraisal  will  be  performed,  and  the  logistics  for  the 
appraisal.  Process  action  plans  usually  result  from  appraisals  and 
document  how  specific  improvements  targeting  the  weaknesses 
uncovered  by  an  appraisal  will  be  implemented.  In  cases  in  which  it  is 
determined  that  the  improvement  described  in  the  process  action  plan 
should  be  tested  on  a  small  group  before  deploying  it  across  the 
organization,  a  pilot  plan  is  generated.  Finally,  when  the  improvement  is 
to  be  deployed,  a  deployment  plan  is  used.  This  plan  describes  when 
and  how  the  improvement  will  be  deployed  across  the  organization. 

[PA152.N104] 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets.  [paiszrioij 


Specific  Goals 


SG  1  Determine  Process-Improvement  Opportunities  [pais2.igioi] 

Strengths,  weaknesses,  and  improvement  opportunities  for  the  organization's 
processes  are  identified  periodically  and  as  needed. 


SG  2  Plan  and  Implement  Process-Improvement  Activities  [PA1521G102] 


Improvements  are  planned  and  implemented,  organizational  process  assets 
are  deployed,  and  process-related  experiences  are  incorporated  into  the 
organizational  process  assets. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 
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GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Determine  Process-Improvement  Opportunities  [pais2.igioi] 

SP  1.1-1  Establish  Organizational  Process  Needs 

SP  1.2-1  Appraise  the  Organization’s  Processes 

SP  1.3-1  Identify  the  Organization's  Process  Improvements 

SG  2  Plan  and  Implement  Process-Improvement  Activities  [PA152.1G102] 

SP  2.1-1  Establish  Process  Action  Plans 
SP  2.2-1  Implement  Process  Action  Plans 

SP  2.3-1  Deploy  Organizational  Process  Assets 

SP  2.4-1  Incorporate  Process-Related  Experiences  into  the  Organizational 
Process  Assets 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioii 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 
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GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 
GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Determine  Process-Improvement  Opportunities 


Strengths,  weaknesses,  and  improvement  opportunities  for  the  organization's 
processes  are  identified  periodically  and  as  needed,  i pais2.igioi ; 

Strengths,  weaknesses,  and  improvement  opportunities  may  be 
determined  relative  to  a  process  standard  or  model  such  as  a  CMMI 
model  or  International  Organization  for  Standardization  (ISO)  standard. 
The  process  improvements  should  be  selected  specifically  to  address 
the  organization's  needs,  [pai52.igioi.nioi] 


SP  1.1-1  Establish  Organizational  Process  Needs 

Establish  and  maintain  the  description  of  the  process  needs  and 
objectives  for  the  organization.  [pais2.igioi.spioii 


The  organization's  processes  operate  in  a  business  context  that  must 
be  understood.  The  organization's  business  objectives,  needs,  and 
constraints  determine  the  needs  and  objectives  for  the  organization’s 
processes.  Typically,  the  issues  related  to  financial,  technological, 
quality,  human  resource,  and  marketing  are  important  process 
considerations,  [pai52.igioi.spioi.nioi] 

The  organization's  process  needs  and  objectives  cover  aspects  that 
include  the  following:  [pai52.igioi.spioi.nio2] 

•  Characteristics  of  the  processes 

•  Process  performance  objectives,  such  as  time  to  market  and 
product  quality 

•  Process  effectiveness 

Typical  Work  Products 

1 .  Organization’s  process  needs  and  objectives  [pai52.igioi.spioi.wioi] 

Subpractices 

1 .  Identify  the  policies,  standards,  and  business  objectives  that  are 
applicable  to  the  organization's  processes.  [PAi52.iGioi.spioi.subPioi] 
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2.  Examine  relevant  process  standards  and  models  for  best  practices. 

[PA152.IG101  .SP101  .SubP102] 

3.  Determine  the  organization’s  process  performance  objectives. 

[PA152.IG101.SP101.SubP103] 

Process  performance  objectives  may  be  expressed  in  quantitative  or  qualitative 
terms.  [PAi52.iGi01.sp101.subPi03.Ni0i] 

Examples  of  process  performance  objectives  include  the  following: 

[PA152.IG101.SP101.SubP103.N102] 

•  Cycle  time 

•  Defect  removal  rates 

•  Productivity 

4.  Define  the  essential  characteristics  of  the  organization’s  processes. 

[PA152.IG101.SP101.SubP104] 

The  essential  characteristics  of  the  organization’s  processes  are  determined 
based  on  the  following:  [PAi52.iGio1.sp101.subPio4.Nioi] 

•  Processes  currently  being  used  in  the  organization 

•  Process  and  product  standards  imposed  by  the  organization 

•  Process  and  product  standards  commonly  imposed  by  customers  of  the 
organization 

Examples  of  process  characteristics  include  the  following:  [PAi52.iGio1.sp101.subPio4.Nio2] 

•  Level  of  detail  used  to  describe  the  processes 

•  Process  notation  used 

•  Granularity  of  the  processes 

5.  Document  the  organization’s  process  needs  and  objectives. 

[PA152.IG101.SP101.SubP105] 

6.  Revise  the  organization’s  process  needs  and  objectives  as 
needed.  [PAi52.iGioi.spioi.subPio6] 


SP  1.2-1  Appraise  the  Organization’s  Processes 

Appraise  the  processes  of  the  organization  periodically  and  as 
needed  to  maintain  an  understanding  of  their  strengths  and 
weaknesses,  [pai52.igioi.spw2] 


Process  appraisals  may  be  performed  for  the  following  reasons: 

[PA152.IG101.SP102.N101] 

•  To  identify  processes  that  should  be  improved 
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•  To  confirm  progress  and  make  the  benefits  of  process 
improvement  visible 

•  To  satisfy  the  needs  of  a  customer-supplier  relationship 

•  To  motivate  and  facilitate  buy-in 

The  buy-in  gained  during  a  process  appraisal  can  be  eroded 
significantly  if  it  is  not  followed  by  an  appraisal-based  action  plan. 

[PA152.IG101.SP102.N102] 

Typical  Work  Products 

1 .  Plans  for  the  organization's  process  appraisals  [pai52.igioi.spio2.wioi] 

2.  Appraisal  findings  that  address  strengths  and  weaknesses  of  the 
organization's  processes  [PAi52.iGi01.sp102.w102] 

3.  Improvement  recommendations  for  the  organization's  processes 

[PA152.IG101.SP102.W103] 

Subpractices 

1 .  Obtain  sponsorship  of  the  process  appraisal  from  senior 
management.  [PAi52.iGioi.spio2.subPioi] 

Senior-management  sponsorship  includes  the  commitment  to  have  the 
organization's  managers  and  staff  participate  in  the  process  appraisal  and  to 
provide  the  resources  and  funding  to  analyze  and  communicate  the  findings  of  the 
appraisal.  [PAi52.iGio1.sp102.subPio1.Nioi] 

2.  Define  the  scope  of  the  process  appraisal.  [PAi52.iGioi.spio2.subPio2] 

Process  appraisals  may  be  performed  on  the  entire  organization  or  may  be 
performed  on  a  smaller  part  of  an  organization  such  as  a  single  project  or 
business  area.  [PAi52.iGio1.sp102.subPio2.Nioi] 

The  scope  of  the  process  appraisal  addresses  the  following: 

[PA152.IG101.SP102.SubP102.N102] 

•  Definition  of  the  organization  (e.g.,  sites  or  business  areas)  that  will  be  covered  by 
the  appraisal 

•  Identification  of  the  project  and  support  functions  that  will  represent  the 
organization  in  the  appraisal 

•  Processes  that  will  be  appraised 

3.  Determine  the  method  and  criteria  for  process  appraisal. 

[PA152.IG101.SP102.SubP103] 
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Process  appraisals  can  occur  in  many  forms.  Process  appraisals  should  address 
the  needs  and  objectives  of  the  organization,  which  may  change  over  time.  For 
example,  the  appraisal  may  be  based  on  a  process  model,  such  as  a  CMMI 
model,  or  on  a  national  or  international  standard,  such  as  ISO  9001 .  The 
appraisals  may  also  be  based  on  a  benchmark  comparison  with  other 
organizations.  The  appraisal  method  may  assume  a  variety  of  characteristics  in 
terms  of  time  and  effort  expended,  makeup  of  the  appraisal  team,  and  the  method 
and  depth  of  investigation.  [PAi52.iGi01.sp102.subPi03.Ni0i] 

4.  Plan,  schedule,  and  prepare  for  the  process  appraisal. 

[PA152.IG101.SP102.SubP104] 

5.  Conduct  the  process  appraisal.  [PAi52.iGioi.spio2.subPios] 

6.  Document  and  deliver  the  appraisal’s  activities  and  findings. 

[PA152.IG101.SP102.SubP106] 


SP  1.3-1  Identify  the  Organization's  Process  Improvements 

Identify  improvements  to  the  organization's  processes  and 
process  assets,  [pais2.igwi.spw3] 

Typical  Work  Products 

1 .  Analysis  of  candidate  process  improvements  [pai52.igioi.spio3.wioi] 

2.  Identification  of  improvements  for  the  organization's  processes 

[PA152.IG101.SP103.W102] 

Subpractices 

1.  Determine  candidate  process  improvements.  [PAi52.iGioi.spio3.subPioi] 
Candidate  process  improvements  are  typically  determined  by  doing  the  following: 

[PA152.IG101.SP103.SubP101.N101] 

•  Measure  the  processes  and  analyze  the  measurement  results 

•  Review  the  processes  for  effectiveness  and  suitability 

•  Review  the  lessons  learned  from  tailoring  the  organization’s  set  of  standard 
processes 

•  Review  the  lessons  learned  from  implementing  the  processes 

•  Review  process-improvement  proposals  submitted  by  the  organization's 
managers  and  staff,  and  other  relevant  stakeholders 

•  Solicit  inputs  on  process  improvements  from  the  senior  management  and  leaders 
in  the  organization 

•  Examine  the  results  of  process  appraisals  and  other  process-related  reviews 

•  Review  results  of  other  organization  improvement  initiatives 

2.  Prioritize  the  candidate  process  improvements.  [PAi52.iGioi.spio3.subPio2] 
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Criteria  for  prioritization  are  as  follows:  [PAi52.iGi01.sp103.subPi02.Ni0i] 

•  Consider  the  estimated  cost  and  effort  to  implement  the  process  improvements 

•  Appraise  the  expected  improvement  against  the  organization's  improvement 
objectives  and  priorities 

•  Determine  the  potential  barriers  to  the  process  improvements  and  develop 
strategies  for  overcoming  these  barriers 


Examples  of  techniques  to  help  determine  and  prioritize  the  possible 

improvements  to  be  implemented  include  the  following:  [PAi52.iGi01.sp103.subPi02.Ni02] 

•  A  gap  analysis  that  compares  current  conditions  in  the  organization  with  optimal 
conditions 

•  Force-field  analysis  of  potential  improvements  to  identify  potential  barriers  and 
strategies  for  overcoming  those  barriers 

•  Cause-and-effect  analyses  to  provide  information  on  the  potential  effects  of 
different  improvements  that  can  then  be  compared 


3.  Identify  and  document  the  process  improvements  that  will  be 
implemented.  [PAi52.iGioi.spio3.subPio3] 

4.  Revise  the  list  of  planned  process  improvements  to  keep  it  current. 

[PA152.IG101.SP103.SubP104] 


SG  2  Plan  and  Implement  Process-Improvement  Activities 


Improvements  are  planned  and  implemented,  organizational  process  assets 
are  deployed,  and  process-related  experiences  are  incorporated  into  the 
organizational  process  assets.  [PA152.1G102] 

Successful  implementation  of  improvements  requires  participation  in  the 
process  definition  and  improvement  activities  by  process  owners,  those 
performing  the  process,  and  support  organizations,  [pai52.igio2.nioi] 


SP  2.1-1  Establish  Process  Action  Plans 

Establish  and  maintain  process  action  plans  to  address 
improvements  to  the  organization's  processes  and  process 

assets.  [PA152.IG102.SP101] 


Establishing  and  maintaining  process  action  plans  typically  involves  the 
following  roles:  [pai52.igio2.spioi.nioi] 

•  Management  steering  committees  to  set  strategies  and  oversee 
process-improvement  activities 

•  Process  group  staff  to  facilitate  and  manage  the  process- 
improvement  activities 

•  Process  action  teams  to  define  and  implement  the  improvement 
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•  Process  owners  to  manage  the  deployment 

•  Practitioners  to  perform  the  process 

This  involvement  helps  to  obtain  buy-in  on  the  process  improvements 
and  increases  the  likelihood  of  effective  deployment,  [pai52.igio2.spioi.nio2] 

Process  action  plans  are  detailed  implementation  plans.  These  plans 
differ  from  the  organization’s  process-improvement  plan  in  that  they  are 
plans  targeting  specific  improvements  that  have  been  defined  to 
address  weaknesses  usually  uncovered  by  appraisals,  [pai52.igio2.spioi.nio3] 

Typical  Work  Products 

1.  Organization's  approved  process  action  plans  [pai52.igio2.spioi.wioi] 

Subpractices 

1 .  Identify  strategies,  approaches,  and  actions  to  address  the 
identified  process  improvements.  [PAi52.iGio2.spioi.subPioi] 

New,  unproven,  and  major  changes  are  piloted  before  they  are  incorporated  into 
normal  use.  [PAi52.iGio2.sp101.subPio1.Nioi] 

2.  Establish  process  action  teams  to  implement  the  actions. 

[PA152.IG102.SP101.SubP102] 

The  teams  and  people  performing  the  process-improvement  actions  are  called 
“process  action  teams.”  Process  action  teams  typically  include  process  owners 
and  those  who  perform  the  process.  [PAi52.iGio2.sp101.subPio2.Nioi] 

3.  Document  process  action  plans.  [PAi52.iGio2.spioi.subPio3] 

Process  action  plans  typically  cover  the  following:  [PAi52.iGi02.sp101.subPi03.Ni0i] 

•  Process-improvement  infrastructure 

•  Process-improvement  objectives 

•  Process  improvements  that  will  be  addressed 

•  Procedures  for  planning  and  tracking  process  actions 

•  Strategies  for  piloting  and  implementing  the  process  actions 

•  Responsibility  and  authority  for  implementing  the  process  actions 

•  Resources,  schedules,  and  assignments  for  implementing  the  process  actions 

•  Methods  for  determining  the  effectiveness  of  the  process  actions 

•  Risks  associated  with  process  action  plans 

4.  Review  and  negotiate  process  action  plans  with  relevant 
stakeholders.  [PAi52.iGio2.spioi.subPio4] 

5.  Review  process  action  plans  as  necessary.  [PAi52.iGio2.spioi.subPio5] 
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SP  2.2-1  Implement  Process  Action  Plans 

Implement  process  action  plans  across  the  organization. 

[PA152.IG102.SP1 02] 


Typical  Work  Products 

1 .  Commitments  among  the  various  process  action  teams 

[PA152.IG102.SP102.W101] 

2.  Status  and  results  of  implementing  process  action  plans 

[PA152.IG102.SP102.W102] 

3.  Plans  for  pilots  [PAi52.IGi02.SPi02.Wi03] 

Subpractices 

1 .  Make  process  action  plans  readily  available  to  relevant 
stakeholders.  [PAi52.iGio2.spio2.subPioi] 

2.  Negotiate  and  document  commitments  among  the  process  action 
teams  and  revise  their  process  action  plans  as  necessary. 

[PA152.!G102.SP102.SubP102] 

3.  Track  progress  and  commitments  against  process  action  plans. 

[PA152.IG102.SP102.SubP103] 

4.  Conduct  joint  reviews  with  the  process  action  teams  and  relevant 
stakeholders  to  monitor  the  progress  and  results  of  the  process 

actions.  [PA152.IG102.SP102.SubP104] 

5.  Plan  pilots  needed  to  test  selected  process  improvements. 

[PA152.IG102.SP102.SubP105] 

6.  Review  the  activities  and  work  products  of  process  action  teams. 

[PA152.IG102.SP102.SubP106] 

7.  Identify,  document,  and  track  to  closure  issues  in  implementing 
process  action  plans.  [PAi52.iGio2.spio2.subPio7] 

8.  Ensure  that  the  results  of  implementing  process  action  plans 
satisfy  the  organization’s  process-improvement  objectives. 

[PA152.IG102.SP102.SubP108] 


SP  2.3-1  Deploy  Organizational  Process  Assets 

Deploy  organizational  process  assets  across  the  organization. 

[PA  152.IG102.SP103] 
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Deployment  of  organizational  process  assets  or  of  changes  to 
organizational  process  assets  should  be  performed  in  an  orderly 
manner.  Some  organizational  process  assets  or  changes  to 
organizational  process  assets  may  not  be  appropriate  for 
implementation  in  some  parts  of  the  organization  (because  of  customer 
requirements  or  the  current  lifecycle  phase  being  implemented,  for 
example).  It  is  therefore  important  that  those  that  are  or  will  be 
executing  the  process,  as  well  as  other  organization  functions  (such  as 
training  and  quality  assurance)  be  involved  in  the  deployment  as 
necessary,  [pais2.igio2.spio3.nioi] 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  how  the  deployment  of  organizational  process  assets 
is  supported  and  enabled  by  the  organization’s  process  asset  library. 

[PA1S2.IG102.SP103.N101.R101] 

Typical  Work  Products 

1 .  Plans  for  deploying  the  organizational  process  assets  and  changes 
to  organizational  process  assets  [PAi52.iGi02.sp103.w10i] 

2.  Training  materials  for  deploying  the  organizational  process  assets 
and  changes  to  organizational  process  assets  [PAi52.iGi02.sp103.w102] 

3.  Documentation  of  changes  to  the  organizational  process  assets 

[PA152.IG102.SP103.W103] 

4.  Support  materials  for  deploying  the  organizational  process  assets 
and  changes  to  organizational  process  assets  [pais2.igio2.spio3.wio4] 

Subpractices 

1 .  Deploy  organizational  process  assets  and  associated  methods  and 

tools.  [PA152.IG102.SP1 03. SubPI 01] 

Typical  activities  performed  as  a  part  of  this  deployment  include  the  following: 

[PA152.IG102.SP103.SubP101.N101] 

•  Planning  the  deployment 

•  Identifying  the  organizational  process  assets  that  should  be  adopted  by  those  who 
will  be  performing  the  process 

•  Ensuring  that  training  is  available  for  the  organizational  process  assets  that  are 
being  deployed 

•  Identifying  the  support  resources  (e.g.,  tools)  needed  to  transition  the  deployed 
organizational  process  assets 

•  Determining  the  schedule  for  deploying  the  organizational  process  assets 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  coordination  of  training. 

[PA152.IG102.SP103.SubP101.N101.R101] 


106 


Process  Management,  Organizational  Process  Focus 


CMMI-SW,  vl.1 
Continuous  Representation 

2.  Deploy  the  changes  that  were  made  to  the  organizational  process 

aSSetS.  [PA152.IG102.SP103.SubP102] 

Typical  activities  performed  as  a  part  of  this  deployment  include  the  following: 

[PA152.IG102.SP103.SubP102.N101] 

•  Planning  the  deployment 

•  Determining  which  changes  are  appropriate  for  those  that  are  or  will  be 
performing  the  process 

•  Determining  the  time  frame  for  deploying  the  changes 

•  Arranging  for  the  associated  support  needed  to  successfully  transition  the 
changes 

3.  Document  the  changes  to  the  organizational  process  assets. 

[PA152.IG102.SP103.SubP103] 

The  documentation  of  changes  is  used  to  understand  the  relationship  of  the 
changes  to  resulting  changes  in  process  performance  and  results. 

[PA152.IG102.SP103.SubP103.N101] 

4.  Provide  guidance  and  consultation  on  the  use  of  the  organizational 
process  assets.  [PAi52.iGio2.spio3.subPio4] 


SP  2.4-1  Incorporate  Process-Related  Experiences  into  the  Organizational 
Process  Assets 

Incorporate  process-related  work  products,  measures,  and 
improvement  information  derived  from  planning  and  performing 
the  process  into  the  organizational  process  assets.  [pais2.igio2.spio4] 


Typical  Work  Products 

1 .  Process-improvement  proposals  [PAi52.iGi02  sp104.w10i] 

2.  Process  lessons  learned  [PAi52.iGi02.sp104.w102] 

3.  Measurements  on  the  organizational  process  assets 

[PA152.IG102.SP104.W103] 

4.  Improvement  recommendations  for  the  organizational  process 

aSSetS  [PA152.IG102.SP104.W104] 

5.  Records  of  the  organization's  process-improvement  activities 

[PA152.IG102.SP104.W105] 

6.  Information  on  the  organizational  process  assets  and 
improvements  to  them  [PAi52.iGi02.sp104.w106] 
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Subpractices 

1 .  Conduct  periodic  reviews  of  the  effectiveness  and  suitability  of  the 
organization’s  set  of  standard  processes  and  related  organizational 
process  assets  relative  to  the  organization’s  business  objectives. 

[PA152.IG102.SP1 04. SubPI  01] 

2.  Obtain  feedback  about  the  use  of  the  organizational  process 

aSSetS.  [PA152.IG102.SP104.SubP102] 

3.  Derive  lessons  learned  from  defining,  piloting,  implementing,  and 
deploying  the  organizational  process  assets.  [PAi52.iGio2.spio4.subPio3] 

4.  Make  lessons  learned  available  to  the  people  in  the  organization  as 
appropriate.  [PAi52.iGio2.spio4.subPio4] 

Actions  may  have  to  be  taken  to  ensure  that  lessons  learned  are  used 
appropriately.  [PAi52.iGi02.sp104.subPi04.Ni0i] 


Examples  of  inappropriate  use  of  lessons  learned  include  the  following: 

[PA152.IG102.SP104.SubP104.N102] 

•  Evaluating  the  performance  of  people 

•  Judging  process  performance  or  results 

Examples  of  ways  to  prevent  inappropriate  use  of  lessons  learned  include  the 
following:  [PAi52.iGio2.sp104.subPio4.Nio3] 

•  Controlling  access  to  the  lessons  learned 

•  Educating  people  about  the  appropriate  use  of  lessons  learned 

5.  Analyze  the  organization's  common  set  of  measures. 

[PA152.IG102.SP104.SubP105] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  analyzing  measures.  [PAi52.iGi02.sp104.subPi0s.Ri0i] 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  an  organizational 
measurement  repository,  including  common  measures. 

[PA152.IG102.SP1 04.  SubPI  05.  R102] 

6.  Appraise  the  processes,  methods,  and  tools  in  use  in  the 
organization  and  develop  recommendations  for  improving  the 
organizational  process  assets.  [PAi52.iGio2.spio4.subPio6] 

This  appraisal  typically  includes  the  following:  [PAi52.iGi02.sp104.subPi06.Ni0i] 

•  Determining  which  of  the  processes,  methods,  and  tools  are  of  potential  use  to 
other  parts  of  the  organization 

•  Appraising  the  quality  and  effectiveness  of  the  organizational  process  assets 
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•  Identifying  candidate  improvements  to  the  organizational  process  assets 

•  Determining  compliance  with  the  organization’s  set  of  standard  processes  and 
tailoring  guidelines 

7.  Make  the  best  use  of  the  organization's  processes,  methods,  and 
tools  available  to  the  people  in  the  organization  as  appropriate. 

[PA152.IG102.SP104.SubP107] 

8.  Manage  process-improvement  proposals.  [PAi52.iGio2.spio4.subPio8] 

The  activities  for  managing  process-improvement  proposals  typically  include  the 
following:  [PAi52.iGio2.sp104.subPio8.Nioi] 

•  Soliciting  process-improvement  proposals 

•  Collecting  process-improvement  proposals 

•  Reviewing  the  process-improvement  proposals 

•  Selecting  the  process-improvement  proposals  that  will  be  implemented 

•  Tracking  the  implementation  of  the  process-improvement  proposals 

Process-improvement  proposals  are  documented  as  process  change  requests  or 
problem  reports,  as  appropriate.  [PAi52.iGi02.sp104.subPi08.Ni02] 

Some  process-improvement  proposals  may  be  incorporated  into  the 
organization’s  process  action  plans.  [PAi52.iGio2.sp104.subPio8.Nio3] 

9.  Establish  and  maintain  records  of  the  organization's  process- 

improvement  activities.  [PA152.IG102.SP104.SubP109] 

Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  organizational  process  focus 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [GP102] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 
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GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  process  focus  process,  [gpiosj 


Elaboration: 

This  policy  establishes  organizational  expectations  for  determining 
process-improvement  opportunities  for  the  processes  being  used  and 
for  planning  and  implementing  process-improvement  activities  across 
the  organization,  [paiszelioii 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  organizational 
process  focus  process,  [gpimj 


Elaboration: 

The  plan  for  performing  the  organizational  process  focus  process, 
which  is  often  called  “the  process-improvement  plan,”  differs  from  the 
process  action  plans  described  in  specific  practices  in  this  process 
area.  The  plan  called  for  in  this  generic  practice  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process 
area,  from  the  establishment  of  organizational  process  needs  all  the 
way  through  to  the  incorporation  of  process-related  experiences  into  the 
organizational  process  assets.  [pai52.elio3] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  focus  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpiosj 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools:  [pais2.elio6] 

•  Database  management  systems 

•  Process-improvement  tools 

•  Web  page  builders  and  browsers 

•  Groupware 

•  Quality-improvement  tools  (e.g.,  quality-improvement  tools,  cause-and-effect 
diagrams,  affinity  diagrams,  Pareto  charts) 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
organizational  process  focus  process,  [gpiobi 


Elaboration: 

Two  groups  are  typically  established  and  assigned  responsibility  for 
process  improvement:  (1)  a  management  steering  committee  for 
process  improvement  to  provide  senior-management  sponsorship;  and 
(2)  a  process  group  to  facilitate  and  manage  the  process-improvement 
activities.  [pai52.eli20] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  focus  process  as  needed,  igpio?] 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pais2.elio7] 

•  CMMI  and  other  process  and  process-improvement  reference  models 

•  Planning  and  managing  process  improvement 

•  Tools,  methods,  and  analysis  techniques 

•  Process  modeling 

•  Facilitation  techniques 

•  Change  management 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
focus  process  under  appropriate  levels  of  configuration 
management,  [gpioqj 
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Elaboration: 


Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai52.elios] 

•  Process-improvement  proposals 

•  Organization’s  approved  process  action  plans 

•  Training  materials  for  deploying  organizational  process  assets 

•  Plans  for  the  organization’s  process  appraisals 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  organizational 
process  focus  process  as  planned.  [GP1241 


Elaboration: 


Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai52.elh9] 

•  Coordinating  and  collaborating  on  process-improvement  activities  with  process 
owners,  those  that  are  or  will  be  performing  the  process,  and  support 
organizations  (e.g.,  training  staff  and  quality  assurance  representatives) 

•  Establishing  the  organizational  process  needs  and  objectives 

•  Appraising  the  organization’s  processes 

•  Implementing  process  action  plans 

•  Coordinating  and  collaborating  on  the  execution  of  pilots  to  test  selected 
improvements 

•  Deploying  organizational  process  assets  and  changes  to  organizational  process 
assets 

•  Communicating  the  plans,  status,  activities,  and  results  related  to  the 
implementation  of  process-improvement  activities 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  focus  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpho] 
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Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA152.EL113] 

•  Number  of  process-improvement  proposals  submitted,  accepted,  or  implemented 

•  CMMI  maturity  level  or  capability  level 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
focus  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance.  [gph3] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai52.elh5] 

•  Determining  process-improvement  opportunities 

•  Planning  and  coordinating  process-improvement  activities 

Examples  of  work  products  reviewed  include  the  following:  [pai52.elh8] 

•  Process-improvement  plans 

•  Process  action  plans 

•  Plans  for  the  organization’s  process  appraisals 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  focus  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


Elaboration: 

These  reviews  are  typically  in  the  form  of  a  briefing  presented  to  the 
management  steering  committee  by  the  process  group  and  the  process 
action  teams.  [pai52.elh6] 
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Examples  of  presentation  topics  include  the  following:  [pais2.eli21] 

•  Status  of  improvements  being  developed  by  process  action  teams 

•  Results  of  pilots 

•  Results  of  deployments 

•  Schedule  status  for  achieving  significant  milestones  (e.g.,  readiness  for  an 
appraisal,  or  progress  towards  achieving  a  targeted  organizational  maturity  level 
or  capability  level  profile) 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  organizational 
process  focus  process,  [gpiui 

Collect  Improvement  Information 

GG  4  Institution: 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  organizational  process  focus  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  17] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  focus  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  igpus] 

Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  focus  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  igpiw] 
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The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  process 
focus  process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP125] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  organizational  process  focus  process.  [GP1211 
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ORGANIZATIONAL  PROCESS  DEFINITION 

Process  Management 


Purpose 


The  purpose  of  Organizational  Process  Definition  is  to  establish  and 
maintain  a  usable  set  of  organizational  process  assets.  [pais3] 


Introductory  Notes 


Organizational  process  assets  enable  consistent  process  performance 
across  the  organization  and  provide  a  basis  for  cumulative,  long-term 
benefits  to  the  organization.  See  Chapter  3  for  an  explanation  of  how 
“organizational  process  assets”  is  used  in  the  CMMI  Product  Suite. 

[PA153.N101] 


The  organization's  process  asset  library  is  a  collection  of  items 
maintained  by  the  organization  for  use  by  the  people  and  projects  of  the 
organization.  This  collection  of  items  includes  descriptions  of  processes 
and  process  elements,  descriptions  of  life-cycle  models,  process 
tailoring  guidelines,  process-related  documentation,  and  data.  The 
organization’s  process  asset  library  supports  organizational  learning 
and  process  improvement  by  allowing  the  sharing  of  best  practices  and 
lessons  learned  across  the  organization.  [PA153.N103] 

The  organization's  set  of  standard  processes  is  tailored  by  projects  to 
create  their  defined  processes.  The  other  organizational  process  assets 
are  used  to  support  tailoring  as  well  as  the  implementation  of  the 
defined  processes.  [pais3.nio4] 

A  standard  process  is  composed  of  other  processes  or  process 
elements.  A  process  element  is  the  fundamental  (e.g.,  atomic)  unit  of 
process  definition  and  describes  the  activities  and  tasks  to  consistently 
perform  work.  Process  architecture  provides  rules  for  connecting  the 
process  elements  of  a  standard  process.  The  organization's  set  of 
standard  processes  may  include  multiple  process  architectures. 

[PA153.N105] 


See  the  definitions  of  “standard  process”  and  “process  element”  in 
Appendix  C,  the  glossary.  See  Chapter  3  for  an  explanation  of  how 
“process  architecture”  is  used  in  the  CMMI  Product  Suite.  [pais3.nio7] 
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The  organizational  process  assets  may  be  organized  in  many  ways,  depending  on  the 
implementation  of  the  Organizational  Process  Definition  process  area.  Examples 
include  the  following:  [pais3.nio6] 

•  Descriptions  of  life-cycle  models  may  be  documented  as  part  of  the  organization's 
set  of  standard  processes,  or  they  may  be  documented  separately. 

•  The  organization's  set  of  standard  processes  may  be  stored  in  the  organization's 
process  asset  library,  or  they  may  be  stored  separately. 

•  A  single  repository  may  contain  both  the  measurements  and  the  process-related 
documentation,  or  they  may  be  stored  separately. 


Related  Process  Areas 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process-related  matters.  [PA153.R1011 

Specific  Goals 

SG  1  Establish  Organizational  Process  Assets  [PA153 .igioi] 

A  set  of  organizational  process  assets  is  established  and  maintained. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clio3.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GG  5  Institutionalize  an  Optimizing  Process  [cliob.glioi] 

_ The  process  is  institutionalized  as  an  optimizing  process. _ | 

Practice-to-Goal  Relationship  Table 

SG  1  Establish  Organizational  Process  Assets  [pais3.igioi] 

SP  1.1-1  Establish  Standard  Processes 

SP  1.2-1  Establish  Life-Cycle  Model  Descriptions 

SP  1.3-1  Establish  Tailoring  Criteria  and  Guidelines 

SP  1 .4-1  Establish  the  Organization’s  Measurement  Repository 

SP  1 .5-1  Establish  the  Organization’s  Process  Asset  Library 

GG  1  Achieve  Specific  Goals  [clkk.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clio4.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 

SG  1  Establish  Organizational  Process  Assets 

_ A  set  of  organizational  process  assets  is  established  and  maintained.  [pais3.igioi]  | 


SP  1.1-1  Establish  Standard  Processes 

Establish  and  maintain  the  organization's  set  of  standard 
processes.  [pai53.igioi.spioi] 
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Standard  processes  may  be  defined  at  multiple  levels  in  an  enterprise 
and  they  may  be  related  in  a  hierarchical  manner.  For  example,  an 
enterprise  may  have  a  set  of  standard  processes  that  is  tailored  by 
individual  organizations  (e.g.,  a  division  or  site)  in  the  enterprise  to 
establish  their  set  of  standard  processes.  The  set  of  standard 
processes  may  also  be  tailored  for  each  of  the  organization’s  business 
areas  or  product  lines.  Thus  “the  organization's  set  of  standard 
processes”  can  refer  to  the  standard  processes  established  at  the 
organization  level  and  standard  processes  that  may  be  established  at 
lower  levels,  although  some  organizations  may  only  have  a  single  level 
of  standard  processes.  See  the  definition  of  “standard  process”  in 
Appendix  C,  the  glossary.  See  Chapter  3  for  an  explanation  of  how 
“organization’s  set  of  standard  processes”  is  used  in  the  CMMI  Product 

Suite.  [PA153.IG101.SP101.N101] 

Multiple  standard  processes  may  be  needed  to  address  the  needs  of 
different  application  domains,  life-cycle  models,  methodologies,  and 
tools.  The  organization's  set  of  standard  processes  contains  process 
elements  (e.g.,  a  work  product  size-estimating  element)  that  may  be 
interconnected  according  to  one  or  more  process  architectures  that 
describe  the  relationships  among  these  process  elements.  Processes 
may  be  composed  of  other  processes  or  process  elements. 

[PA153.IG101.SP101.N102] 


The  organization's  set  of  standard  processes  typically  includes 
technical,  management,  administrative,  support,  and  organizational 

processes.  [PA153.IG101.SP101.N103] 


The  organization’s  set  of  standard  processes  should  collectively  cover 
all  processes  needed  by  the  organization  and  projects,  including  those 
processes  addressed  by  the  process  areas  at  Maturity  Level  2. 

[PA153.IG101.SP101.N104] 

Typical  Work  Products 

1 .  Organization's  set  of  standard  processes  [pai53.igioi.spioi.wioi] 

Subpractices 

1.  Decompose  each  standard  process  into  constituent  process 
elements  to  the  detail  needed  to  understand  and  describe  the 

process.  [PA153.IG101.SP101.SubP101] 


Each  process  element  covers  a  bounded  and  closely  related  set  of  activities.  The 
descriptions  of  the  process  elements  may  be  templates  to  be  filled  in,  fragments 
to  be  completed,  abstractions  to  be  refined,  or  complete  descriptions  to  be  tailored 
or  used  unmodified.  These  elements  are  described  in  sufficient  detail  such  that 
the  process,  when  fully  defined,  can  be  consistently  performed  by  appropriately 
trained  and  skilled  people.  [PAi53.iGioi.spioi.subPioi.Nioi] 
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Examples  of  process  elements  include  the  following:  [PAi53.iGi01.sp101.subPi01.Ni02] 

•  Template  for  generating  work  product  size  estimates 

•  Description  of  work  product  design  methodology 

•  Tailorable  peer  review  methodology 

•  Template  for  conduct  of  management  reviews 

2.  Specify  the  critical  attributes  of  each  process  element. 

[PA153.IG101.SP101.SubP102] 

Examples  of  critical  attributes  include  the  following:  [PAi53.iGio1.sp101.subPio2.moi] 

•  Process  roles 

•  Applicable  process  and  product  standards 

•  Applicable  procedures,  methods,  tools,  and  resources 

•  Process  performance  objectives 

•  Entry  criteria 

•  Inputs 

•  Product  and  process  measures  to  be  collected  and  used 

•  Verification  points  (e.g.,  peer  reviews) 

•  Outputs 

•  Interfaces 

•  Exit  criteria 

3.  Specify  the  relationships  of  the  process  elements. 

[PA153.IG101.SP101.SubP103] 

Examples  of  relationships  include  the  following:  [PAi53.iGi01.sp101.subPi03.Ni0i] 

•  Ordering  of  the  process  elements 

•  Interfaces  among  the  process  elements 

•  Interfaces  with  external  processes 

•  Interdependencies  among  the  process  elements 


The  rules  for  describing  the  relationships  among  process  elements  are  referred  to 
as  “process  architecture.”  The  process  architecture  covers  the  essential 
requirements  and  guidelines.  The  detailed  specifications  of  these  relationships  are 
covered  in  the  descriptions  of  the  defined  processes  that  are  tailored  from  the 
organization's  set  of  standard  processes.  [PAi53.iGi01.sp101.subPi03.Ni02] 

4.  Ensure  that  the  organization's  set  of  standard  processes  adheres 
to  applicable  policies;  process  standards  and  models;  and  product 
standards.  [PAi53.iGioi.spioi.subPio4] 
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Adherence  to  applicable  process  standards  and  models  is  typically  demonstrated 
by  developing  a  mapping  from  the  organization’s  set  of  standard  processes  to  the 
relevant  process  standards  and  models.  In  addition,  this  mapping  will  be  a  useful 
input  to  future  appraisals.  [PAi53.iGi01.sp101.subPi04.Ni0i] 

5.  Ensure  that  the  organization’s  set  of  standard  processes  satisfies 
the  process  needs  and  objectives  of  the  organization. 

[PA153.IG101.SP101.SubP105] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  establishing  and  maintaining  the  organization’s 
process  needs  and  objectives.  [PAi53.iGi01.sp101.subPi05.Ri0i] 

6.  Ensure  that  there  is  appropriate  integration  among  the  processes 
that  are  included  in  the  organization’s  set  of  standard  processes. 

[PA153.IG101.SP101.SubP106] 

7.  Document  the  organization's  set  of  standard  processes. 

[PA153.IG101.SP101.SubP107] 

8.  Conduct  peer  reviews  on  the  organization's  set  of  standard 
processes.  [PAi53.iGioi.spioi.subPio8] 

Refer  to  the  Verification  process  area  for  more  information  about 
peer  review.  [PAi53.iGi01.sp101.subPi0a.Ri0i] 

9.  Revise  the  organization's  set  of  standard  processes  as  necessary. 

[PA153.IG101.SP101.SubP109] 


SP  1.2-1  Establish  Life-Cycle  Model  Descriptions 

Establish  and  maintain  descriptions  of  the  life-cycle  models 
approved  for  use  in  the  organization.  [pais3.igioi.spio2i 


Life-cycle  models  may  be  developed  for  a  variety  of  customers  or  in  a 
variety  of  situations,  since  one  life-cycle  model  may  not  be  appropriate 
for  all  situations.  The  organization  may  identify  more  than  one  life-cycle 
model  for  use.  Typically,  the  organization  needs  both  product  and 
project  life-cycle  models,  for  the  types  of  products  that  it  produces  and 
for  defining  the  phases  of  the  project,  [pai53.igioi.spio2.nioi] 

Product  life-cycle  models  partition  the  product  life  cycle  into  phases  for 
which  activities  and  requirements  can  be  defined  to  promote  a  complete 
solution,  from  initiating  development  of  the  product  to  its  ultimate 

diSpOSal.  [PA153.IG101.SP102.N102] 

Typical  Work  Products 

1 .  Descriptions  of  life-cycle  models  [PAi53.iGi01.sp102.w10i] 
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Subpractices 

1 .  Select  life-cycle  models  based  on  the  needs  of  projects  and  the 
organization.  [PAi53.iGioi.spio2.subPioi] 

For  example,  in  the  case  of  a  development  project,  project  life-cycle  models 
include  the  following:  [PAi53.iGi01.sp102.subPi01.Ni0i] 

•  Waterfall 

•  Spiral 

•  Evolutionary 

•  Incremental 

•  Iterative 

Examples  of  project  characteristics  that  could  affect  the  project  life-cycle  models 
include  the  following:  [PAi53.iGi01.sp102.subPi01.Ni02] 

•  Size  of  the  project 

•  Experience  and  familiarity  of  project  staff  in  implementing  the  process 

•  Constraints  such  as  cycle  time  and  acceptable  defect  levels 

2.  Document  the  descriptions  of  the  life-cycle  models. 

[PA153.IG101.SP102.SubP102] 

The  life-cycle  models  may  be  documented  as  part  of  the  organization's  standard 
process  descriptions  or  they  may  be  documented  separately. 

[PA153.IG101.SP102.SubP102.N101] 

3.  Conduct  peer  reviews  on  the  life-cycle  models.  [PAi53.iGioi.spio2.subPio3] 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews.  [PAi53.iGio1.spw2.subPio3.Rioi] 

4.  Revise  the  descriptions  of  the  life-cycle  models  as  necessary. 

[PA153.IG101.SP102.SubP104] 


SP  1.3-1  Establish  Tailoring  Criteria  and  Guidelines 

Establish  and  maintain  the  tailoring  criteria  and  guidelines  for  the 
organization's  set  of  standard  processes,  [pai53.igioi.spw3] 


The  tailoring  criteria  and  guidelines  describe  the  following: 

[PA153.IG101.SP103.N101] 

•  How  the  organization's  set  of  standard  processes  and 

organizational  process  assets  are  used  to  create  the  defined 
processes 
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•  Mandatory  requirements  that  must  be  satisfied  by  the  defined 
processes  (e.g.,  the  subset  of  the  organizational  process  assets 
that  are  essential  for  any  defined  process) 

•  Options  that  can  be  exercised  and  criteria  for  selecting  among  the 
options 

•  Procedures  that  must  be  followed  in  performing  and  documenting 
process  tailoring 

Examples  of  reasons  for  tailoring  include  the  following:  [pai53.igioi.spio3.nio2] 

•  Adapting  the  process  for  a  new  product  line  or  host  environment 

•  Customizing  the  process  for  a  specific  application  or  class  of  applications  (e.g., 
initial  development,  maintenance,  or  creation  of  prototypes) 

•  Elaborating  the  process  description  so  that  the  resulting  defined  process  can  be 
performed 


Flexibility  in  tailoring  and  defining  processes  is  balanced  with  ensuring 
appropriate  consistency  in  the  processes  across  the  organization. 
Flexibility  is  needed  to  address  contextual  variables  such  as  the 
domain;  nature  of  the  customer;  cost,  schedule,  and  quality  tradeoffs; 
technical  difficulty  of  the  work;  and  experience  of  the  people 
implementing  the  process.  Consistency  across  the  organization  is 
needed  so  that  organizational  standards,  objectives,  and  strategies  are 
appropriately  addressed,  and  process  data  and  lessons  learned  can  be 

shared.  [PA153.IG101.SP103.N103] 

Tailoring  criteria  and  guidelines  may  allow  for  using  a  standard  process 
“as  is,”  with  no  tailoring,  [pais3.igioi.spio3.nio4] 

Typical  Work  Products 

1 .  Tailoring  guidelines  for  the  organization's  set  of  standard 

processes  [PA153.IG101.SP103.W101] 

Subpractices 

1 .  Specify  the  selection  criteria  and  procedures  for  tailoring  the 
organization's  set  of  standard  processes.  [pai53.igioi  spio3.subPioi] 


Examples  of  criteria  and  procedures  include  the  following:  [PAi53.iGi01.sp103.subPi01.Ni0i] 

•  Criteria  for  selecting  life-cycle  models  from  those  approved  by  the  organization 

•  Criteria  for  selecting  process  elements  from  the  organization's  set  of  standard 
processes 

•  Procedures  for  tailoring  the  selected  life-cycle  models  and  process  elements  to 
accommodate  specific  process  characteristics  and  needs 
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Examples  of  tailoring  actions  include  the  following:  [PAi53.iGi01.sp103.subPi01.Ni02] 

•  Modifying  a  life-cycle  model 

•  Combining  elements  of  different  life-cycle  models 

•  Modifying  process  elements 

•  Replacing  process  elements 

•  Reordering  process  elements 

2.  Specify  the  standards  for  documenting  the  defined  processes. 

[PA153.IG101.SP103.SubP102] 

3.  Specify  the  procedures  for  submitting  and  obtaining  approval  of 
waivers  from  the  requirements  of  the  organization's  set  of  standard 

prOCeSSeS.  [PA153.IG101.SP103.SubP103] 

4.  Document  the  tailoring  guidelines  for  the  organization's  set  of 
standard  processes.  [PAi53.iGioi.spio3.subPio4] 

5.  Conduct  peer  reviews  on  the  tailoring  guidelines. 

[PA153.IG101.SP103.SubP105] 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews.  1 PAi53.iGi01.sp103.subPi05.Ri01 7 

6.  Revise  the  tailoring  guidelines  as  necessary.  [PAi53.iGioi.spio3.subPioe] 


SP  1.4-1  Establish  the  Organization’s  Measurement  Repository 

Establish  and  maintain  the  organization’s  measurement 
repository.  [pais3.igioi.spw4] 


Refer  to  the  Use  Organizational  Process  Assets  for  Planning  Project 
Activities  specific  practice  of  the  Integrated  Project  Management 
process  area  for  more  information  about  the  use  of  the  organization’s 
measurement  repository  in  planning  project  activities,  [pai53.igwi.spio4.rioi] 

The  repository  contains  both  product  and  process  measures  that  are 
related  to  the  organization's  set  of  standard  processes.  It  also  contains 
or  refers  to  the  information  needed  to  understand  and  interpret  the 
measures  and  assess  them  for  reasonableness  and  applicability.  For 
example,  the  definitions  of  the  measures  are  used  to  compare  similar 
measures  from  different  processes,  [pai53.igioi.spio4.nioi] 

Typical  Work  Products 

1 .  Definition  of  the  common  set  of  product  and  process  measures  for 
the  organization's  set  of  standard  processes  [pai53.igioi.spio4.wioi] 

2.  Design  of  the  organization’s  measurement  repository 

[PA153.IG101.SP104.W102] 
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3.  Organization's  measurement  repository  (i.e. ,  the  repository 
structure  and  support  environment)  [pai53.igioi.spio4.wio3] 

4.  Organization’s  measurement  data  [pai53.igioi.spio4.wio4] 

Subpractices 

1 .  Determine  the  organization's  needs  for  storing,  retrieving,  and 
analyzing  measurements.  [PAi53.iGioi.spio4.subPioi] 

2.  Define  a  common  set  of  process  and  product  measures  for  the 
organization's  set  of  standard  processes.  [pai53.igioi  spio4.subPio2] 

The  measures  in  the  common  set  are  selected  based  on  the  organization's  set  of 
standard  processes.  The  common  set  of  measures  may  vary  for  different  standard 
processes.  [PAi53.iGio1.sp104.subPio2.Nioi] 

Operational  definitions  for  the  measures  specify  the  procedures  for  collecting  valid 
data  and  the  point  in  the  process  where  the  data  will  be  collected. 

[PA153.IG101.SP104.SubP102.N102] 


Examples  of  classes  of  commonly  used  measures  include  the  following: 

[PA153.IG101.SP104.SubP102.N103] 

•  Estimates  of  work  product  size  (e.g.,  pages) 

•  Estimates  of  effort  and  cost  (e.g.,  person  hours) 

•  Actual  measures  of  size,  effort,  and  cost 

•  Quality  measures  (e.g.,  number  of  defects  found,  severity  of  defects) 

•  Peer  review  coverage 

•  Test  coverage 

•  Reliability  measures  (e.g.,  mean  time  to  failure) 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures.  [PAis3.iGi01.spw4.subPi02.Ni03.Ri0i] 

3.  Design  and  implement  the  measurement  repository. 

[PA153.IG101.SP104.SubP103] 

4.  Specify  the  procedures  for  storing,  updating,  and  retrieving 
measures.  [PAi53.iGioi.spio4.subPio4] 

5.  Conduct  peer  reviews  on  the  definitions  of  the  common  set  of 
measures  and  the  procedures  for  storing  and  retrieving  measures. 

[PA153.IG101.SP104.SubP105] 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews.  1 PAi53.iGi01.spw4.subPi05.Ri01 7 

6.  Enter  the  specified  measures  into  the  repository. 

[PA1 53.IG1 01  .SP1 04.SubP1 06] 
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Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting  and  analyzing  data. 

[PA1S3.IG101.SP104.SubP106.R101] 

7.  Make  the  contents  of  the  measurement  repository  available  for  use 
by  the  organization  and  projects  as  appropriate.  [PAi53.iGioi.spio4.subPio7] 

8.  Revise  the  measurement  repository,  common  set  of  measures,  and 
procedures  as  the  organization’s  needs  change.  [PAi53.iGioi.spio4.subPio8] 

Examples  of  when  the  common  set  of  measures  may  need  to  be  revised  include 
the  following:  [PAi53.iGio1.sp104.subPio8.Nioi] 

•  New  processes  are  added 

•  Processes  are  revised  and  new  product  or  process  measures  are  needed 

•  Finer  granularity  of  data  is  required 

•  Greater  visibility  into  the  process  is  required 

•  Measures  are  retired 

SP  1.5-1  Establish  the  Organization’s  Process  Asset  Library 

Establish  and  maintain  the  organization's  process  asset  library. 

[PA153.IG101  .SP105] 

Examples  of  items  to  be  stored  in  the  organization’s  process  asset  library  include  the 

following:  [PA153.IG101.SP105.N101] 

•  Organizational  policies 

•  Defined  process  descriptions 

•  Procedures  (e.g.,  estimating  procedure) 

•  Development  plans 

•  Quality  assurance  plans 

•  Training  materials 

•  Process  aids  (e.g.,  checklists) 

•  Lessons-learned  reports 


Typical  Work  Products 

1 .  Design  of  the  organization’s  process  asset  library  [pai53.igioi.spio5.wioi] 

2.  Organization's  process  asset  library  [PAi53.iGi01.sp105.w102] 

3.  Selected  items  to  be  included  in  the  organization’s  process  asset 

library  [PA153.IG101.SP10S.W103] 

4.  Catalog  of  items  in  the  organization’s  process  asset  library 

[PA153.IG101.SP105.W104] 
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Subpractices 

1 .  Design  and  implement  the  organization’s  process  asset  library, 
including  the  library  structure  and  support  environment. 

[PA153.IG101.SP105.SubP101] 

2.  Specify  the  criteria  for  including  items  in  the  library. 

[PA1 53.IG1 01  .SP1 05.SubP1 02] 

The  items  are  selected  based  primarily  on  their  relationship  to  the  organization's 
set  of  standard  processes.  [PAi53.iGi01.sp105.subPi02.Ni0i] 

3.  Specify  the  procedures  for  storing  and  retrieving  items. 

[PA153.IG101.SP105.SubP103] 

4.  Enter  the  selected  items  into  the  library  and  catalog  them  for  easy 
reference  and  retrieval.  [PAi53.iGioi.spio5.subPio4] 

5.  Make  the  items  available  for  use  by  the  projects. 

[PA153.IG101.SP105.SubP105] 

6.  Periodically  review  the  use  of  each  item  and  use  the  results  to 
maintain  the  library  contents.  [PAi53.iGioi.spio5.subPio6] 

7.  Revise  the  organization’s  process  asset  library  as  necessary. 

[PA153.IG101.SP105.SubP107] 

Examples  of  when  the  library  may  need  to  be  revised  include  the  following: 

[PA153.IG101.SP105.SubP107.N101] 

•  New  items  are  added 

•  Items  are  retired 

•  Current  versions  of  items  are  changed 

Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  organizational  process  definition 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [GP1021 
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GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  process  definition  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  a  set  of  standard  processes  for  use  by  the  organization  and 
making  organizational  process  assets  available  across  the  organization. 

[PA153.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  organizational 
process  definition  process.  [gpio4} 


Elaboration: 

Typically,  this  plan  for  performing  the  organizational  process  definition 
process  is  a  part  of  the  organization’s  process-improvement  plan. 

[PA153.EL102] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  definition  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpios] 


Elaboration: 

A  process  group  typically  manages  the  organizational  process  definition 
activities.  This  group  is  typically  staffed  by  a  core  of  professionals 
whose  primary  responsibility  is  coordinating  organizational  process 
improvement.  This  group  is  supported  by  process  owners  and  people 
with  expertise  in  various  disciplines  such  as  the  following:  [pai53.elios] 

•  Project  management 

•  The  appropriate  engineering  disciplines 

•  Configuration  management 

•  Quality  assurance 


128 


Process  Management,  Organizational  Process  Definition 


CMMI-SW,  vl.1 
Continuous  Representation 


Examples  of  other  resources  provided  include  the  following  tools:  [pai53.elio6] 

•  Database  management  systems 

•  Process  modeling  tools 

•  Web  page  builders  and  browsers 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
organizational  process  definition  process,  [gpiobj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  definition  process  as  needed,  [g P1071 


Elaboration: 

Examples  of  training  topics  include  the  following:  [pai53  elio7] 

•  CMMI  and  other  process  and  process-improvement  reference  models 

•  Planning,  managing,  and  monitoring  processes 

•  Process  modeling  and  definition 

•  Developing  a  tailorable  standard  process 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
definition  process  under  appropriate  levels  of  configuration 
management,  [g pioy 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais3.elio3] 

•  Organization’s  set  of  standard  processes 

•  Descriptions  of  the  life-cycle  models 

•  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 

•  Definitions  of  the  common  set  of  product  and  process  measures 

•  Organization’s  measurement  data 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  organizational 
process  definition  process  as  planned,  igpvmi 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pais3.elih] 

•  Reviewing  the  organization’s  set  of  standard  processes 

•  Reviewing  the  organization’s  life-cycle  models 

•  Resolving  issues  on  the  tailoring  guidelines 

•  Assessing  the  definitions  of  the  common  set  of  process  and  product  measures 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  definition  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuo] 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA153.EL104] 

•  Percentage  of  projects  using  the  process  architectures  and  process  elements  of 
the  organization's  set  of  standard  processes 

•  Defect  density  of  each  process  element  of  the  organization’s  set  of  standard 
processes 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
definition  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [gpusi 


Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai53.elio5] 
•  Establishing  organizational  process  assets 
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Examples  of  work  products  reviewed  include  the  following:  [pai53.elho] 

•  Organization’s  set  of  standard  processes 

•  Descriptions  of  the  life-cycle  models 

•  Tailoring  guidelines  for  the  organization’s  set  of  standard  processes 

•  Organization’s  measurement  data 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  definition  process  with  higher  level  management  and 
resolve  issues.  igpu2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  organizational 
process  definition  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  organizational  process  definition  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  17] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  definition  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gpusj 
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GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  definition 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  [gpiw] 


GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  process 
definition  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization,  [gpusj 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  organizational  process  definition  process,  [g P1211 
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ORGANIZATIONAL  TRAINING 

Process  Management 


Purpose 


The  purpose  of  Organizational  Training  is  to  develop  the  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently,  [paissj 


Introductory  Notes 


Organizational  Training  includes  training  to  support  the  organization’s 
strategic  business  objectives  and  to  meet  the  tactical  training  needs  that 
are  common  across  projects  and  support  groups.  Specific  training 
needs  identified  by  individual  projects  and  support  groups  are  handled 
at  the  project  and  support  group  level  and  are  outside  the  scope  of 
Organizational  Training.  Project  and  support  groups  are  responsible  for 
identifying  and  addressing  their  specific  training  needs,  [paiss.nioi] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects,  [paiss.nioi.rioi] 

An  organizational  training  program  involves  the  following:  [pai58.nio2] 

•  Identifying  the  training  needed  by  the  organization 

•  Obtaining  and  providing  training  to  address  those  needs 

•  Establishing  and  maintaining  training  capability 

•  Establishing  and  maintaining  training  records 

•  Assessing  training  effectiveness 

Effective  training  requires  assessment  of  needs,  planning,  instructional 
design,  and  appropriate  training  media  (e.g.,  workbooks,  computer 
software),  as  well  as  a  repository  of  training  process  data.  As  an 
organizational  process,  the  main  components  of  training  include  a 
managed  training-development  program,  documented  plans,  personnel 
with  appropriate  mastery  of  specific  disciplines  and  other  areas  of 
knowledge,  and  mechanisms  for  measuring  the  effectiveness  of  the 
training  program,  [paiss.nkb] 

The  identification  of  process  training  needs  is  primarily  based  on  the 
skills  that  are  required  to  perform  the  organization's  set  of  standard 
processes,  [paiss.nkm] 


Process  Management,  Organizational  Training 


133 


CMMI-SW,  vl.1 
Continuous  Representation 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  set  of  standard  processes. 

[PA158.N104.R101] 


Certain  skills  may  be  effectively  and  efficiently  imparted  through 
vehicles  other  than  in-class  training  experiences  (e.g.,  informal 
mentoring).  Other  skills  require  more  formalized  training  vehicles,  such 
as  in  a  classroom,  by  Web-based  training,  through  guided  self  study,  or 
via  a  formalized  on-the-job  training  program.  The  formal  or  informal 
training  vehicles  employed  for  each  situation  should  be  based  on  an 
assessment  of  the  need  for  training  and  the  performance  gap  to  be 
addressed.  The  term  “training”  used  throughout  this  process  area  is 
used  broadly  to  include  all  of  these  learning  options,  [paiss.nios] 

Success  in  training  can  be  measured  in  terms  of  the  availability  of 
opportunities  to  acquire  the  skills  and  knowledge  needed  to  perform 
new  and  ongoing  enterprise  activities,  [paiss.nios] 

Skills  and  knowledge  may  be  technical,  organizational,  or  contextual. 
Technical  skills  pertain  to  the  ability  to  use  the  equipment,  tools, 
materials,  data,  and  processes  required  by  a  project  or  process. 
Organizational  skills  pertain  to  behavior  within  and  according  to  the 
employee's  organization  structure,  role  and  responsibilities,  and  general 
operating  principles  and  methods.  Contextual  skills  are  the  self¬ 
management,  communication,  and  interpersonal  abilities  needed  to 
successfully  perform  in  the  organizational  and  social  context  of  the 
project  and  support  groups,  [paiss.nwi 

The  phrase  “project  and  support  groups”  is  used  frequently  in  the  text  of 
the  process  area  description  to  indicate  an  organization-level 
perspective,  [paiss.nios] 


Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization's  process  assets.  [pais8.rioii 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  specific  training  needs  identified  by  projects.  [pais8.rio2] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  determining  training  approaches. 

[PA158.R103] 
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SG  1  Establish  an  Organizational  Training  Capability  [paissigioi] 


A  training  capability  that  supports  the  organization's  management  and 
technical  roles  is  established  and  maintained. 


SG  2  Provide  Necessary  Training  [paiss  igioi 


Training  necessary  for  individuals  to  perform  their  roles  effectively  is 
provided. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Establish  an  Organizational  Training  Capability  [paiss.igiou 
SP  1.1-1  Establish  the  Strategic  Training  Needs 
SP  1 .2-1  Determine  Which  T raining  Needs  Are  the  Responsibility  of  the 
Organization 

SP  1.3-1  Establish  an  Organizational  Training  Tactical  Plan 
SP  1.4-1  Establish  Training  Capability 
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SG  2  Provide  Necessary  Training  [pai58.igio2] 


SP  2.1-1 

Deliver  Training 

SP  2.2-1 

Establish  Training  Records 

SP  2.3-1 

Assess  Training  Effectiveness 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [clio3.ghoi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clio4.glioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliooglioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Establish  an  Organizational  Training  Capability 


A  training  capability  that  supports  the  organization's  management  and 
technical  roles  is  established  and  maintained,  [paiss.igioi] 

The  organization  identifies  the  training  required  to  develop  the  skills  and 
knowledge  necessary  to  perform  enterprise  activities.  Once  the  needs 
are  identified,  a  training  program  addressing  those  needs  is  developed. 

[PA158.IG101.N101] 


SP  1.1-1  Establish  the  Strategic  Training  Needs 

Establish  and  maintain  the  strategic  training  needs  of  the 
organization,  [paiss.igioi. spioi] 
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Examples  of  sources  of  strategic  training  needs  include  the  following:  [paiss.igioi.spioi.nioi] 

•  Organization's  standard  processes 

•  Organization's  strategic  business  plan 

•  Organization's  process-improvement  plan 

•  Enterprise-level  initiatives 

•  Skill  appraisals 

•  Risk  analyses 


Typical  Work  Products 

1.  Training  needs  [paiss.igioi.spioi.wioi] 

2.  Assessment  analysis  [paiss.igioi.spioi.wioi 

Subpractices 

1 .  Analyze  the  organization's  strategic  business  objectives  and 
process-improvement  plan  to  identify  potential  future  training 
needs.  [PAiss.iGioi.spioi.subPioi] 

2.  Document  the  strategic  training  needs  of  the  organization. 

[PA1 58.IG1 01  .SP1 01  .SubPI  02] 


Examples  of  categories  of  training  needs  include  (but  are  not  limited  to)  the 

following:  [PA158.IG101.SP101.SubP102.N101] 

•  Process  analysis  and  documentation 

•  Engineering  (e.g.,  requirements  analysis,  design,  testing,  configuration 
management,  and  quality  assurance) 

•  Selection  and  management  of  suppliers 

•  Management  (e.g.,  estimating,  tracking,  and  risk  management) 

3.  Determine  the  roles  and  skills  needed  to  perform  the  organization's 
set  of  standard  processes.  [PAi58.iGioi.spioi.subPio3] 

4.  Document  the  training  needed  to  perform  the  roles  in  the 
organization's  set  of  standard  processes,  [paiss.igioi ,spioi.subPio4] 

5.  Revise  the  organization’s  strategic  needs  and  required  training  as 
necessary,  [paiss.igioi.spioi .subPi osi 


SP  1.2-1  Determine  Which  Training  Needs  Are  the  Responsibility  of  the 
Organization 

Determine  which  training  needs  are  the  responsibility  of  the 
organization  and  which  will  be  left  to  the  individual  project  or 
Support  group,  [paisb.igioi.spw2] 
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Refer  to  the  Project  Planning  process  area  for  more  information  about 
project-  and  support-group-specific  plans  for  training,  [pm58.igioi.spio2.rioi] 

In  addition  to  strategic  training  needs,  organizational  training  addresses 
training  requirements  that  are  common  across  projects  and  support 
groups.  Projects  and  support  groups  have  the  primary  responsibility  for 
identifying  and  addressing  their  specific  training  needs.  The 
organization’s  training  staff  is  only  responsible  for  addressing  common 
cross-project  and  support-group  training  needs.  In  some  cases, 
however,  the  organization’s  training  staff  may  address  additional 
training  needs  of  projects  and  support  groups,  as  negotiated  with  them, 
within  the  context  of  the  training  resources  available  and  the 
organization's  training  priorities,  [pai58.igioi.spio2.nioi] 

Typical  Work  Products 

1 .  Common  project  and  support  group  training  needs 

[PA158.IG101.SP102.W101] 

2.  Training  commitments  [pai58.igioi.spio2.wio2] 

Subpractices 

1 .  Analyze  the  training  needs  identified  by  the  various  projects  and 
support  groups.  [PAi58.iGioi.spio2.subPioi] 

Analysis  of  project  and  support  group  needs  is  intended  to  identify  common 
training  needs  that  can  be  most  efficiently  addressed  organization  wide.  These 
needs-analysis  activities  are  used  to  anticipate  future  training  needs  that  are  first 
visible  at  the  project  and  support  group  level.  [PAi58.iGi01.sp102.subPi01.Ni0i] 

2.  Negotiate  with  the  various  projects  and  support  groups  on  how 
their  specific  training  needs  will  be  satisfied.  [PAi58.iGioi.spio2.subPio2] 

The  support  provided  by  the  organization’s  training  staff  depends  on  the  training 
resources  available  and  the  organization’s  training  priorities. 

[PA158.IG101.SP102.SubP102.N101] 


Examples  of  training  appropriately  performed  by  the  project  or  support  group 
include  the  following:  [PAi58.iGi01.sp102.subPi02.Ni02] 

•  Training  in  the  application  domain  of  the  project 

•  Training  in  the  unique  tools  and  methods  used  by  the  project  or  support  group 

3.  Document  the  commitments  for  providing  training  support  to  the 
projects  and  support  groups.  [PAi58.iGioi.sp«>2.subPio3] 


SP  1.3-1  Establish  an  Organizational  Training  Tactical  Plan 

Establish  and  maintain  an  organizational  training  tactical  plan. 

[PA158.IG101  .SP103] 
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The  organizational  training  tactical  plan  is  the  plan  to  deliver  the  training 
that  is  the  responsibility  of  the  organization.  This  plan  is  adjusted 
periodically  in  response  to  changes  (e.g.,  in  needs  or  resources)  and  to 
evaluations  of  effectiveness,  [pai58.igioi.spio3.nioi] 

Typical  Work  Products 

1.  Organizational  training  tactical  plan  [pai58.igioi.spio3.wioi] 

Subpractices 

1 .  Establish  plan  content.  [PAi58.iGioi.spio3.subPioi] 

Organizational  training  tactical  plans  typically  contain  the  following: 

[PA158.IG101.SP103.SubP101.N101] 

•  Training  needs 

•  Training  topics 

•  Schedules  based  on  training  activities  and  their  dependencies 

•  Methods  used  for  training 

•  Requirements  and  quality  standards  for  training  materials 

•  Training  tasks,  roles,  and  responsibilities 

•  Required  resources  including  tools,  facilities,  environments,  staffing,  and  skills  and 
knowledge 

2.  Establish  commitments  to  the  plan.  [PAi58.iGioi.spio3.subPio2] 

Documented  commitments  by  those  responsible  for  implementing  and  supporting 
the  plan  are  essential  for  the  plan  to  be  effective.  [PAi58.iGi01.sp103.subPi02.Ni0i] 

3.  Revise  plan  and  commitments  as  necessary.  [PAi58.iGioi.spio3.subPio3] 


SP  1.4-1  Establish  Training  Capability 

Establish  and  maintain  training  capability  to  address 
organizational  training  needs,  [paisb.igioi.spiov 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  how  to 
apply  decision-making  criteria  when  selecting  training  approaches  and 
developing  training  materials,  [pais8.igioi.spw4.rioi] 

Typical  Work  Products 

1.  Training  materials  and  supporting  artifacts  [pai58.igioi.spio4.wioi] 

Subpractices 

1 .  Select  the  appropriate  approaches  to  satisfy  specific  organizational 
training  needs.  [PAi58.iGioi.spio4.subPioi] 
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Many  factors  may  affect  the  selection  of  training  approaches,  including  audience- 
specific  knowledge,  costs  and  schedule,  work  environment,  and  so  on.  Selection 
of  an  approach  requires  consideration  of  the  means  to  provide  skills  and 
knowledge  in  the  most  effective  way  possible  given  the  constraints. 

[PA158.IG101.SP104.SubP101.N101] 

Examples  of  training  approaches  include  the  following:  [PAi58.iGioi.spio4.subPioi.Nio2] 

•  Classroom  training 

•  Computer-aided  instruction 

•  Guided  self  study 

•  Formal  apprenticeship  and  mentoring  programs 

•  Facilitated  videos 

•  Chalk  talks 

•  Brown-bag  lunch  seminars 

•  Structured  on-the-job  training 

2.  Determine  whether  to  develop  training  materials  internally  or 
acquire  them  externally.  [PAi58.iGioi.spio4.subPio2] 

Determine  the  costs  and  benefits  of  internal  training  development  or  of  obtaining 
training  externally.  [PAi58.iGio1.sp104.subPio2.Nioi] 

Example  criteria  that  can  be  used  to  determine  the  most  effective  mode  of 
knowledge  or  skill  acquisition  include  the  following:  [PAi58.iGio1.sp104.subPio2.Nio2] 

•  Performance  objectives 

•  Time  available  to  prepare  for  project  execution 

•  Business  objectives 

•  Availability  of  in-house  expertise 

•  Availability  of  training  from  external  sources 

Examples  of  external  sources  of  training  include  the  following: 

[PA158.IG101.SP104.SubP102.N103] 

•  Customer-provided  training 

•  Commercially  available  training  courses 

•  Academic  programs 

•  Professional  conferences 

•  Seminars 

3.  Develop  or  obtain  training  materials.  [PAi58.iGioi.spio4.subPio3] 
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Training  may  be  provided  by  the  project,  by  support  groups,  by  the  organization, 
or  by  an  external  organization.  The  organization's  training  staff  coordinates  the 
acquisition  and  delivery  of  training  regardless  of  its  source.  [PAi58.iGioi.spio4.subPio3.Nioi] 


Examples  of  training  materials  include  the  following:  [PAi58.iGi01.sp104.subPi03.Ni02] 

•  Courses 

•  Computer-aided  instruction 

•  Videos 

4.  Develop  or  obtain  qualified  instructors.  [PAi58.iGioi.spio4.subPio6] 

To  ensure  that  internally  provided  training  instructors  have  the  necessary 
knowledge  and  training  skills,  criteria  can  be  defined  to  identify,  develop,  and 
qualify  them.  In  the  case  of  externally  provided  training,  the  organization’s  training 
staff  may  investigate  how  the  training  provider  determines  which  instructors  will 
deliver  the  training.  This  can  also  be  a  factor  in  selecting  or  continuing  to  use  a 
specific  training  provider.  [PAi58.iGioi.spio4.subPio6.Nioi] 

5.  Describe  the  training  in  the  organization's  training  curriculum. 

[PA158.IG101.SP104.SubP104] 


Examples  of  the  information  provided  in  the  training  descriptions  for  each  course 
include  the  following:  [PAi58.iGi01.sp104.subPi04.Ni0i] 

•  Topics  covered  in  the  training 

•  Intended  audience 

•  Prerequisites  and  preparation  for  participating 

•  Training  objectives 

•  Length  of  the  training 

•  Lesson  plans 

•  Completion  criteria  for  the  course 

•  Criteria  for  granting  training  waivers 

6.  Revise  the  training  materials  and  supporting  artifacts  as  necessary. 

[PA158.IG101.SP104.SubP105] 


Examples  of  situations  in  which  the  training  materials  and  supporting  artifacts  may 
need  to  be  revised  include  the  following:  [PAi58.iGi01.sp104.subPi05.Ni0i] 

•  Training  needs  change  (e.g.,  when  new  technology  associated  with  the  training 
topic  is  available) 

•  An  evaluation  of  the  training  identifies  the  need  for  change  (e.g. ,  evaluations  of 
training-effectiveness  surveys,  training  program  performance  assessments,  or 
instructor  evaluation  forms) 
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SG  2  Provide  Necessary  Training 


Training  necessary  for  individuals  to  perform  their  roles  effectively  is 
provided,  [paiss.igiov 

In  selecting  people  to  be  trained,  the  following  should  be  taken  into 

consideration:  [pai58.igio2.nioi] 

•  Background  of  the  target  population  of  training  participants 

•  Prerequisite  background  to  receive  training 

•  Skills  and  abilities  needed  by  people  to  perform  their  roles 

•  Need  for  cross-discipline  technical-management  training  for  all 
disciplines,  including  project  management 

•  Need  for  managers  to  have  training  in  appropriate  organizational 
processes 

•  Need  for  training  in  the  basic  principles  of  discipline-specific 
engineering  to  support  personnel  in  quality  management, 
configuration  management,  and  other  related  support  functions 

•  Need  to  provide  competency  development  for  critical  functional 
areas 


SP  2.1-1  Deliver  Training 

Deliver  the  training  following  the  organizational  training  tactical 

plan.  [PA1 58.IG102.SP1 01] 


Typical  Work  Products 

1.  Delivered  training  course  [pai58.igio2.spioi.wioi] 

Subpractices 

1 .  Select  the  people  who  will  receive  the  training.  [PAi58.iGio2.spioi.subPioi] 

Training  is  intended  to  impart  knowledge  and  skills  to  people  performing  various 
roles  within  the  organization.  Some  people  already  possess  the  knowledge  and 
skills  required  to  perform  well  in  their  designated  roles.  Training  can  be  waived  for 
these  people,  but  care  should  be  taken  that  training  waivers  are  not  abused. 

[PA158.IG102.SP101.SubP101.N101] 

2.  Schedule  the  training,  including  any  resources,  as  necessary  (e.g., 
facilities  and  instructors).  [PAi58.iGio2.spioi.subPio2] 

Training  should  be  planned  and  scheduled.  Training  is  provided  that  has  a  direct 
bearing  on  the  expectations  of  work  performance.  Therefore,  optimal  training 
occurs  in  a  timely  manner  with  regard  to  imminent  job-performance  expectations. 
These  expectations  often  include  the  following:  [PAi58.iGi02.sp101.subPi02.Ni0i] 

•  Training  in  the  use  of  specialized  tools 
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•  Training  in  procedures  that  are  new  to  the  individual  who  will  perform  them 

3.  Conduct  the  training.  [PAi58.iGio2.spioi.subPio3] 

Experienced  instructors  should  perform  training.  When  possible,  training  is 
conducted  in  settings  that  closely  resemble  actual  performance  conditions  and 
includes  activities  to  simulate  actual  work  situations.  This  approach  includes 
integration  of  tools,  methods,  and  procedures  for  competency  development. 
Training  is  tied  to  work  responsibilities  so  that  on-the-job  activities  or  other  outside 
experiences  will  reinforce  the  training  within  a  reasonable  time  after  the  training. 

[PA158.IG102.SP101.SubP103.N101] 

4.  T rack  the  delivery  of  training  against  the  plan.  [PAi58.iGio2.spioi.subPio4] 


SP  2.2-1  Establish  Training  Records 

Establish  and  maintain  records  of  the  organizational  training. 

[ PA158.IG102.SP1 02 ] 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
on  how  project-  or  support-group  training  records  are  maintained. 

[PA158.IG102.SP102.R101] 

The  scope  of  this  practice  is  for  the  training  performed  at  the 
organizational  level.  Establishment  and  maintenance  of  training  records 
for  project-  or  support-group-sponsored  training  is  the  responsibility  of 
each  individual  project  or  support  group,  [pai58.igio2.spio2.nioi] 

Typical  Work  Products 

1.  Training  records  [PAi58.iGi02sp102.w10i] 

2.  Training  updates  to  the  organizational  repository  [PAi58.iGi02.sp102.w102] 

Subpractices 

1 .  Keep  records  of  all  students  who  successfully  complete  each 
training  course  or  other  approved  training  activity  as  well  as  those 
who  are  unsuccessful.  [PAi58.iGio2.spio2.subPioi] 

2.  Keep  records  of  all  staff  who  have  been  waived  from  specific 
training.  [PAi58.iGio2.spio2.subPio2] 

The  rationale  for  granting  a  waiver  should  be  documented,  and  both  the  manager 
responsible  and  the  manager  of  the  excepted  individual  should  approve  the 
waiver  for  organizational  training.  [PAi58.iGio2.sp102.subPio2.Nioi] 

3.  Keep  records  of  all  students  who  successfully  complete  their 
designated  required  training.  [PAi58.iGio2.spio2.subPio3] 

4.  Make  training  records  available  to  the  appropriate  people  for 
consideration  in  assignments.  [PAi58.iGio2.spio2.subPio4] 
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Training  records  may  be  part  of  a  skills  matrix  developed  by  the  training 
organization  to  provide  a  summary  of  the  experience  and  education  of  people,  as 
well  as  training  sponsored  by  the  organization.  [PAi58.iGi02.sp102.subPi04.Ni0i] 


SP  2.3-1  Assess  Training  Effectiveness 

Assess  the  effectiveness  of  the  organization’s  training  program. 

[PA  158.IG102.SP103] 

A  process  should  exist  to  determine  the  effectiveness  of  training  (i.e., 
how  well  the  training  is  meeting  the  organization’s  needs). 

[PA158.IG102.SP103.N101] 

Examples  of  methods  used  to  assess  training  effectiveness  include  the  following: 

[PA158.IG102.SP103.N103] 

•  Testing  in  the  training  context 

•  Post-training  surveys  of  training  participants 

•  Surveys  of  managers’  satisfaction  with  post-training  effects 

•  Assessment  mechanisms  embedded  in  courseware 


Measures  may  be  taken  to  assess  the  added  value  of  the  training 
against  both  the  project’s  and  organization’s  objectives.  Particular 
attention  should  be  paid  to  the  need  for  various  training  methods,  such 
as  training  teams  as  integral  work  units.  When  used,  performance 
objectives  should  be  shared  with  course  participants,  and  should  be 
unambiguous,  observable,  and  verifiable.  The  results  of  the  training¬ 
effectiveness  assessment  should  be  used  to  revise  training  materials  as 
described  in  the  Establish  Training  Capability  specific  practice  above. 

[PA158.IG102.SP103.N102] 

Typical  Work  Products 

1.  Training-effectiveness  surveys  [pai58.igio2.spio3.wioi] 

2.  Training  program  performance  assessments  [pai58.igio2.spio3.wio2] 

3.  Instructor  evaluation  forms  [pai58.igio2.spio3.wio3] 

4.  Training  examinations  [pais8.igio2.spio3.wio4] 

Subpractices 

1 .  Assess  in-progress  or  completed  projects  to  determine  whether 
staff  knowledge  is  adequate  for  performing  project  tasks. 

[PA158.IG102.SP1 03. SubPI  01] 
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2.  Provide  a  mechanism  for  assessing  the  effectiveness  of  each 
training  course  with  respect  to  established  organizational,  project, 
or  individual  learning  (or  performance)  objectives. 

[PA158.IG102.SP103.SubP102] 

3.  Obtain  student  evaluations  of  how  well  training  activities  met  their 

needs.  [PA158.IG102.SP103.SubP103] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  organizational  training  process 
to  develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area.  [GP1021 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  training  process.  [GP1031 


Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  the 
strategic  training  needs  of  the  organization,  and  providing  that  training. 

[PA158.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  organizational 
training  process,  [gpiov 
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Elaboration: 

This  plan  for  performing  the  organizational  training  process  differs  from 
the  tactical  plan  for  organizational  training  described  in  a  specific 
practice  in  this  process  area.  The  plan  called  for  in  this  generic  practice 
would  address  the  comprehensive  planning  for  all  of  the  specific 
practices  in  this  process  area,  from  the  establishment  of  strategic 
training  needs  all  the  way  through  to  the  assessment  of  the 
effectiveness  of  the  organizational  training  effort.  In  contrast,  the 
organizational  training  tactical  plan  called  for  in  the  specific  practice 
would  address  the  periodic  planning  for  the  delivery  of  individual 
training  offerings,  [paiss.elick] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
training  process,  developing  the  work  products,  and  providing  the 
services  of  the  process,  [gpios] 

Elaboration: 


Examples  of  people  (full  or  part  time,  internal  or  external),  and  skills  needed  include  the 
following:  [pais8.elio4] 

•  Subject  matter  experts 

•  Curriculum  designers 

•  Instructional  designers 

•  Instructors 

•  Training  administrators 


Special  facilities  may  be  required  for  training.  When  necessary,  the 
facilities  required  for  the  activities  in  the  Organizational  Training  process 
area  are  developed  or  purchased,  [paiss.elhs] 

Examples  of  other  resources  provided  include  the  following  tools:  [paiss.elios] 

•  Instruments  for  analyzing  training  needs 

•  Workstations  to  be  used  for  training 

•  Instructional  design  tools 

•  Packages  for  developing  presentation  materials 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
organizational  training  process,  igpiobj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
training  process  as  needed,  igpioti 


Elaboration: 

Examples  of  training  topics  include  the  following:  [paiss  eliosj 

•  Knowledge  and  skills  needs  analysis 

•  Instructional  design 

•  Instructional  techniques  (e.g.,  train  the  trainer) 

•  Refresher  training  on  subject  matter 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  training 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais8.elio9] 

•  Organizational  training  tactical  plan 

•  Training  records 

•  Training  materials  and  supporting  artifacts 

•  Instructor  evaluation  forms 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  organizational 
training  process  as  planned.  [gpi24] 
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Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [paiss  elhs] 

•  Establishing  a  collaborative  environment  for  discussion  of  training  needs  and 
training  effectiveness  to  ensure  that  the  organization’s  training  needs  are  met 

•  Identifying  training  needs 

•  Reviewing  the  organizational  training  tactical  plan 

•  Assessing  training  effectiveness 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  training  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action,  [gpuoj 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA158.EL112] 

•  Number  of  training  courses  delivered  (e.g.,  planned  versus  actual) 

•  Post-training  evaluation  ratings 

•  Training  program  quality  survey  ratings 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  training 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [GP1131 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [paiss.ehm] 

•  Identifying  training  needs  and  making  training  available 

•  Providing  necessary  training 

Examples  of  work  products  reviewed  include  the  following:  [pai58.elh6] 

•  Organizational  training  tactical  plan 

•  Training  materials  and  supporting  artifacts 

•  Instructor  evaluation  forms 


148 


Process  Management,  Organizational  Training 


CMMI-SW,  vl.1 
Continuous  Representation 


GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institution; 

Review  the  activities,  status,  and  results  of  the  organizational 
training  process  with  higher  level  management  and  resolve  issues. 

[GP112] 

alize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  organizational 
training  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  organizational  training  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[GP117] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  training  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP118] 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  training  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  r gphs ; 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 
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GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  training 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP1251 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  organizational  training  process.  [GP121] 
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ORGANIZATIONAL  PROCESS  PERFORMANCE 

Process  Management 


Purpose 


The  purpose  of  Organizational  Process  Performance  is  to  establish  and 
maintain  a  quantitative  understanding  of  the  performance  of  the 
organization’s  set  of  standard  processes  in  support  of  quality  and 
process-performance  objectives,  and  to  provide  the  process 
performance  data,  baselines,  and  models  to  quantitatively  manage  the 
organization’s  projects.  [pai64] 


Introductory  Notes 


Process  performance  is  a  measure  of  the  actual  results  achieved  by 
following  a  process.  Process  performance  is  characterized  by  both 
process  measures  (e.g.,  effort,  cycle  time,  and  defect  removal 
effectiveness)  and  product  measures  (e.g.,  reliability  and  defect 
density).  [pai64.nioi] 

The  common  measures  for  the  organization  are  composed  of  process 
and  product  measures  that  can  be  used  to  summarize  the  actual 
performance  of  processes  in  individual  projects  in  the  organization.  The 
organizational  data  for  these  measures  are  analyzed  to  establish  a 
distribution  and  range  of  results,  which  characterize  the  expected 
performance  of  the  process  when  used  on  any  individual  project  in  the 
organization.  [pai64nio2] 

In  this  process  area,  the  phrase  “quality  and  process-performance 
objectives”  covers  objectives  and  requirements  for  product  quality, 
service  quality,  and  process  performance.  As  indicated  above,  the  term 
“process  performance”  includes  product  quality;  however,  to  emphasize 
the  importance  of  product  quality,  the  phrase  “quality  and  process- 
performance  objectives”  is  used  rather  than  just  “process-performance 
objectives.”  [pai64.nio6] 

The  expected  process  performance  can  be  used  in  establishing  the 
project’s  quality  and  process-performance  objectives  and  can  be  used 
as  a  baseline  against  which  actual  project  performance  can  be 
compared.  This  information  is  used  to  quantitatively  manage  the 
project.  Each  quantitatively  managed  project,  in  turn,  provides  actual 
performance  results  that  become  a  part  of  the  baseline  data  for  the 
organizational  process  assets.  [pai64.nio3] 
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The  associated  process  performance  models  are  used  to  represent 
past  and  current  process  performance  and  to  predict  future  results  of 
the  process.  For  example,  the  latent  defects  in  the  delivered  product 
can  be  predicted  using  measurements  of  defects  identified  during  the 
product  verification  activities.  [pai64.nio4] 

When  the  organization  has  measures,  data,  and  analytic  techniques  for 
critical  process  and  product  characteristics,  it  is  able  to  do  the  following: 

[PA164.N105] 

•  Determine  whether  processes  are  behaving  consistently  or  have 
stable  trends  (i.e.,  are  predictable) 

•  Identify  processes  where  the  performance  is  within  natural  bounds 
that  are  consistent  across  process  implementation  teams 

•  Establish  criteria  for  identifying  whether  a  process  or  process 
element  should  be  statistically  managed,  and  determine  pertinent 
measures  and  analytic  techniques  to  be  used  in  such  management 

•  Identify  processes  that  show  unusual  (e.g.,  sporadic  or 
unpredictable)  behavior 

•  Identify  any  aspects  of  the  processes  that  can  be  improved  in  the 
organization's  set  of  standard  processes 

•  Identify  the  implementation  of  a  process  which  performs  best 

Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process  performance  baselines  and 
models,  [paim.rioi] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  specifying  measures  and  collecting  and  analyzing 

data.  [PA164.R102] 


Specific  Goals 


SG  1  Establish  Performance  Baselines  and  Models  [pai64igioii 

Baselines  and  models  that  characterize  the  expected  process  performance  of 
the  organization's  set  of  standard  processes  are  established  and  maintained. 
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Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Establish  Performance  Baselines  and  Models  [pai64.igioi] 

SP  1.1-1  Select  Processes 

SP  1.2-1  Establish  Process  Performance  Measures 

SP  1.3-1  Establish  Quality  and  Process-Performance  Objectives 
SP  1.4-1  Establish  Process  Performance  Baselines 
SP  1.5-1  Establish  Process  Performance  Models 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 
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GG  3  Institutionalize  a  Defined  Process  [clim.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioii 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliobglioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Establish  Performance  Baselines  and  Models 


Baselines  and  models  that  characterize  the  expected  process  performance  of 
the  organization's  set  of  standard  processes  are  established  and  maintained. 

[PA164.IG101] 

Prior  to  establishing  process  performance  baselines  and  models,  it  is 
necessary  to  determine  which  processes  are  suitable  to  be  measured 
(the  Select  Processes  specific  practice),  which  measures  are  useful  for 
determining  process  performance  (the  Establish  Process  Performance 
Measures  specific  practice),  and  the  quality  and  process-performance 
objectives  for  those  processes  (the  Establish  Quality  and  Process- 
Performance  Objectives  specific  practice).  These  specific  practices  are 
often  interrelated  and  may  need  to  be  performed  concurrently  to  select 
the  appropriate  processes,  measures,  and  quality  and  process- 
performance  objectives.  Often,  the  selection  of  one  process,  measure, 
or  objective  will  constrain  the  selection  of  the  others.  For  example,  if  a 
certain  process  is  selected,  the  measures  and  objectives  for  that 
process  may  be  constrained  by  the  process  itself,  [pai64.igioi.nioi] 


SP  1.1-1  Select  Processes 

Select  the  processes  or  process  elements  in  the  organization's  set 
of  standard  processes  that  are  to  be  included  in  the  organization's 
process  performance  analyses.  [paib4.igioi.spioi] 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  structure  of  the  organizational  process  assets. 

[PA164.IG101.SP101.R101] 


The  organization's  set  of  standard  processes  consists  of  a  set  of 
standard  processes  that,  in  turn,  are  composed  of  process  elements. 

[PA164.IG101.SP101.N101] 
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SP  1.2-1 


Typically,  it  will  not  be  possible,  useful,  or  economically  justifiable  to 
apply  statistical  management  techniques  to  all  processes  or  process 
elements  of  the  organization's  set  of  standard  processes.  Selection  of 
the  processes  and/or  process  elements  is  based  upon  the  needs  and 
objectives  of  both  the  organization  and  projects,  [pai64.igioi.spioi.nio2] 

Typical  Work  Products 

1 .  List  of  processes  or  process  elements  identified  for  process 
performance  analyses  [pai64.igioi.spioi.wioi] 


Establish  Process  Performance  Measures 

Establish  and  maintain  definitions  of  the  measures  that  are  to  be 
included  in  the  organization's  process  performance  analyses. 

[PA1 64.IG101  .SP1 02] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  selecting  measures,  [pm64.igwi.spio2.rioi] 

Typical  Work  Products 

1 .  Definitions  for  the  selected  measures  of  process  performance 

[PA164.IG101.SP102.W101] 

Subpractices 

1 .  Determine  which  of  the  organization's  business  objectives  for 
quality  and  process  performance  need  to  be  addressed  by  the 
measures.  [PAi64.iGioi.spio2.subPioi] 

2.  Select  measures  that  provide  appropriate  insight  into  the 
organization's  quality  and  process  performance.  [PAi64.iGioi.spio2.subPio2] 

The  Goal  Question  Metric  paradigm  is  an  approach  that  can  be  used  to  select 
measures  that  provide  insight  into  the  organization’s  business  objectives. 

[PA164.IG101.SP102.SubP102.N101] 
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Examples  of  criteria  used  to  select  measures  include  the  following: 

[PA164.IG101.SP102.SubP102.N102] 

•  Relationship  of  the  measures  to  the  organization’s  business  objectives 

•  Coverage  that  the  measures  provide  over  the  entire  life  of  the  product 

•  Visibility  that  the  measures  provide  into  the  process  performance 

•  Availability  of  the  measures 

•  Extent  to  which  the  measures  are  objective 

•  Frequency  at  which  the  observations  of  the  measure  can  be  collected 

•  Extent  to  which  the  measures  are  controllable  by  changes  to  the  process 

•  Extent  to  which  the  measures  represent  the  users’  view  of  effective  process 
performance 

3.  Incorporate  the  selected  measures  into  the  organization's  set  of 
common  measures.  [PAi64.iGioi.spio2.subPio3] 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  organizational  process  assets. 

[PA164.IG101.SP102.SubP103.R101] 

4.  Revise  the  set  of  measures  as  necessary.  [PAi64.iGioi.spio2.subPio4] 


SP  1.3-1  Establish  Quality  and  Process-Performance  Objectives 

Establish  and  maintain  quantitative  objectives  for  quality  and 
process  performance  for  the  organization,  [pai64.igioi.spw3] 

The  organization's  quality  and  process-performance  objectives  should 
have  the  following  attributes:  [pai64.igioi.spio3.nioi] 

•  Based  on  the  organization's  business  objectives 

•  Based  on  the  past  performance  of  projects 

•  Defined  to  gauge  process  performance  in  areas  such  as  product 
quality,  productivity,  or  cycle  time 

•  Constrained  by  the  inherent  variability  or  natural  bounds  of  the 
process 

Typical  Work  Products 

1 .  Organization's  quality  and  process-performance  objectives 

[PA164.IG101.SP103.W101] 

Subpractices 

1 .  Review  the  organization's  business  objectives  related  to  quality 
and  process  performance.  [PAi64.iGioi.spio3.subPioi] 
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Examples  of  business  objectives  include  the  following:  [PAi64.iGioi.spio3.subPioi.Nioi] 

•  Achieve  a  development  cycle  of  a  specified  duration  for  a  specified  release  of  a 
product 

•  Decrease  the  cost  of  maintenance  of  the  products  by  a  specified  percent 


2.  Define  the  organization's  quantitative  objectives  for  quality  and 
process  performance.  [PAi64.iGioi.spio3.subPio2] 

Objectives  may  be  established  for  both  process  measurements  (e.g.,  effort,  cycle 
time,  and  defect  removal  effectiveness)  and  product  measurements  (e.g., 
reliability  and  defect  density).  [PAie4.iGi01.sp103.subPi02.Ni0i] 


Examples  of  quality  and  process-performance  objectives  include  the  following: 

[PA164.IG101.SP103.SubP102.N102] 

•  Achieve  a  specified  productivity 

•  Deliver  work  products  with  no  more  than  a  specified  number  of  latent  defects 

3.  Define  the  priorities  of  the  organization's  objectives  for  quality  and 
process  performance.  [PAi64.iGioi.spio3.subPio3] 

4.  Review,  negotiate,  and  obtain  commitment  for  the  organization's 
quality  and  process-performance  objectives  and  their  priorities  from 
the  relevant  stakeholders.  [PAi64.iGioi.spio3.subPio4] 

5.  Revise  the  organization's  quantitative  objectives  for  quality  and 
process  performance  as  necessary.  [PAi64.iGioi.spio3.subPios] 


Examples  of  when  the  organization’s  quantitative  objectives  for  quality  and 
process  performance  may  need  to  be  revised  include  the  following: 

[PA164.IG101.SP103.SubP105.N101] 

•  When  the  organization’s  business  objectives  change 

•  When  the  organization’s  processes  change 

•  When  actual  quality  and  process  performance  differs  significantly  from  the 
objectives 


SP  1.4-1  Establish  Process  Performance  Baselines 

Establish  and  maintain  the  organization's  process  performance 
baselines,  ipai64.igioi.spw4] 


The  organization's  process  performance  baselines  are  a  measurement 
of  performance  for  the  organization's  set  of  standard  processes  at 
various  levels  of  detail,  as  appropriate.  The  processes  include  the 

following:  [PA164.IG101.SP104.N101] 

•  Individual  process  elements  (e.g.,  test-case  inspection  element) 
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•  Sequence  of  connected  processes 

•  Processes  that  cover  the  entire  life  of  the  project 

•  Processes  for  developing  individual  work  products 

There  may  be  several  process  performance  baselines  to  characterize 
performance  for  subgroups  of  the  organization,  [pai64.igioi.spio4.nio2] 


Examples  of  criteria  used  to  categorize  subgroups  include  the  following: 

[PA164.IG101.SP104.N104] 

•  Product  line 

•  Application  domain 

•  Complexity 

•  Team  size 

•  Work  product  size 

•  Process  elements  from  the  organization's  set  of  standard  processes 

Allowable  tailoring  of  the  organization’s  set  of  standard  processes  may 
significantly  affect  the  comparability  of  the  data  for  inclusion  in  process 
performance  baselines.  The  effects  of  tailoring  should  be  considered  in 
establishing  baselines,  [pai64.igioi.spio4.nio3] 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process  performance  baselines. 

[PA1B4.IG101.SP104.N103.R101] 

Typical  Work  Products 

1 .  Baseline  data  on  the  organization’s  process  performance 

[PA164.IG101.SP104.W101] 

Subpractices 

1 .  Collect  measurements  from  the  organization’s  projects. 

[PA164.IG101.SP104.SubP101] 

The  process  in  use  when  the  measurement  was  taken  is  recorded  to  enable 
appropriate  use  at  a  later  date.  [PAi64.iGioi.spio4.subPioi.Nioi] 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  collecting  and  analyzing  data. 

[PA164.IG101.SP104.SubP101.N101.R101] 

2.  Establish  and  maintain  the  organization's  process  performance 
baselines  from  the  collected  measurements  and  analyses. 

[PA1 64.IG1 01  .SP1 04.SubP1 02] 
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Refer  to  the  Measurement  and  Analysis  process  area  for 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

[PA164.IG101.SP104.SubP102.R101] 


Process  performance  baselines  are  derived  by  analyzing  the  collected  measures 
to  establish  a  distribution  and  range  of  results  that  characterize  the  expected 
performance  for  selected  processes  when  used  on  any  individual  project  in  the 
organization.  [PAi64.iGio1.sp104.subPio2.Nio2] 

The  measurements  from  stable  processes  from  projects  should  be  used;  other 
data  may  not  be  reliable.  [PAi64.iGio1.sp104.subPio2.Nioi] 

3.  Review  and  get  agreement  with  relevant  stakeholders  about  the 
organization's  process  performance  baselines.  [PAi64.iGioi.spio4.subPio3] 

4.  Make  the  organization's  process  performance  information  available 
across  the  organization  in  the  organization's  measurement 
repository.  [PAi64.iGioi.spio4.subPio4] 

The  organization's  process  performance  baselines  are  used  by  the  projects  to 
estimate  the  natural  bounds  for  process  performance.  [PAi64.iGioi.spio4.subPio4.Nioi] 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  the  organization’s 
measurement  repository.  [PAi64.iGi01.sp104.subPi04.Ni01.Ri0i] 

5.  Compare  the  organization’s  process  performance  baselines  to  the 
associated  objectives.  [PAi64.iGioi.spio4.subPio5] 

6.  Revise  the  organization's  process  performance  baselines  as 
necessary.  [PAi64.iGioi.spio4.subPio6] 


Examples  of  when  the  organization’s  process  performance  baselines  may  need  to 
be  revised  include  the  following:  [PAi64.iGioi.spio4.subPio6.Nioi] 

•  When  the  processes  change 

•  When  the  organization’s  results  change 

•  When  the  organization’s  needs  change 


SP  1.5-1  Establish  Process  Performance  Models 

Establish  and  maintain  the  process  performance  models  for  the 
organization's  set  of  standard  processes.  [pai64.igioi.spios] 
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Process  performance  models  are  used  to  estimate  or  predict  the  value 
of  a  process  performance  measure  from  the  values  of  other  process 
and  product  measurements.  These  process  performance  models 
typically  use  process  and  product  measurements  collected  throughout 
the  life  of  the  project  to  estimate  progress  toward  achieving  objectives 
that  cannot  be  measured  until  later  in  the  project’s  life,  [pai64.igioi.spio5.nioi] 

The  process  performance  models  are  used  as  follows:  [pai64.igioi.spio5.nio2] 

•  The  organization  uses  them  for  estimating,  analyzing,  and 
predicting  the  process  performance  associated  with  the  processes 
in  the  organization's  set  of  standard  processes. 

•  The  organization  uses  them  to  assess  the  (potential)  return  on 
investment  for  process-improvement  activities. 

•  Projects  use  them  for  estimating,  analyzing,  and  predicting  the 
process  performance  for  their  defined  processes. 

•  Projects  use  them  for  selecting  processes  for  use. 

These  measures  and  models  are  defined  to  provide  insight  into  and  to 
provide  the  ability  to  predict  critical  process  and  product  characteristics 
that  are  relevant  to  business  value,  [pai64.igioi.spios.nio3] 


Examples  of  areas  of  concern  to  projects  in  which  models  may  be  useful  include  the 

following:  [PA164.IG101.SP105.N104] 

•  Schedule  and  cost 

•  Reliability 

•  Defect  identification  and  removal  rates 

•  Defect  removal  effectiveness 

•  Latent  defect  estimation 

•  Project  progress 

•  Combinations  of  these  areas 


Examples  of  process  performance  models  include  the  following:  [pai64.igioi.spio5.nio5] 

•  System  dynamics  models 

•  Reliability  growth  models 

•  Complexity  models 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  use  of  process  performance  models. 

IPA164.IG101.SP105.N105.R101] 

Typical  Work  Products 

1 .  Process  performance  models  [pai64.igioi.spio5.wioi] 
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Subpractices 

1.  Establish  the  process  performance  models  based  on  the 
organization's  set  of  standard  processes  and  the  organization's 
process  performance  baselines.  [PAi64.iGioi.spio5.subPioi] 

2.  Calibrate  the  process  performance  models  based  on  the 
organization’s  past  results  and  current  needs.  [PAm.iGioi.spios.subPiog 

3.  Review  the  process  performance  models  and  get  agreement  with 
relevant  stakeholders.  [PAi64.iGioi.spio5.subPio3] 

4.  Support  the  projects'  use  of  the  process  performance  models. 

[PA164.IG101.SP105.SubP104] 

5.  Revise  the  process  performance  models  as  necessary. 

[PA164.IG101.SP105.SubP105] 


Examples  of  when  the  process  performance  models  may  need  to  be  revised 
include  the  following:  [PAi64.iGi01.sp105.subPi05.Ni0i] 

•  When  the  processes  change 

•  When  the  organization's  results  change 

•  When  the  organization's  needs  change 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  organizational  process 
performance  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  process  performance  process.  [gpio3] 
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Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  process  performance  baselines  for  the  organization's  set  of 
standard  processes.  [pai64.elioii 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  organizational 
process  performance  process,  [gpiov 


Elaboration: 

This  plan  for  performing  the  organizational  process  performance 
process  may  be  included  in  or  referenced  by  the  organization’s 
process-improvement  plan,  which  is  described  in  the  Organizational 
Process  Focus  process  area,  or  it  may  be  documented  in  a  separate 
plan  that  describes  only  the  plan  for  the  organizational  process 
performance  process.  [pai64.elh3] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
process  performance  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpios] 


Elaboration: 

Special  expertise  in  statistics  and  statistical  process  control  may  be 
needed  to  establish  the  process  performance  baselines  for  the 
organization's  set  of  standard  processes.  [pai64.elih] 


Examples  of  other  resources  provided  include  the  following  tools:  [pai64.eho2] 

•  Database  management  systems 

•  System  dynamic  models 

•  Process  modeling  tools 

•  Statistical  analysis  packages 

•  Problem-tracking  packages 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
organizational  process  performance  process,  igpiobi 
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GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
process  performance  process  as  needed,  [g pio7] 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pai64.elio3] 

•  Process  and  process-improvement  modeling 

•  Quantitative  and  statistical  methods  (e.g.,  estimating  models,  Pareto  analysis,  and 
control  charts) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  process 
performance  process  under  appropriate  levels  of  configuration 
management,  [gpios] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai64.elio4] 

•  Organization’s  quality  and  process-performance  objectives 

•  Definition  for  the  selected  measures  of  process  performance 

•  Baseline  data  on  the  organization's  process  performance 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  organizational 
process  performance  process  as  planned.  [gpi24] 


Elaboration: 


Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai64.elh2] 

•  Establishing  the  organization’s  quality  and  process-performance  objectives  and 
their  priorities 

•  Reviewing  and  resolving  issues  on  the  organization’s  process  performance 
baselines 

•  Reviewing  and  resolving  issues  on  the  organization’s  process  performance 
models 
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GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  process  performance 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action,  [g phoj 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA1 64.EL1 05] 

•  Trends  in  the  organization’s  process  performance  with  respect  to  changes  in  work 
products  and  task  attributes  (e.g.,  size  growth,  effort,  schedule,  and  quality) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  process 
performance  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance.  [gph3] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai64.eho6] 

•  Establishing  process  performance  baselines  and  models 

Examples  of  work  products  reviewed  include  the  following:  [paim.elhoi 

•  Process  performance  plans 

•  Organization’s  quality  and  process-performance  objectives 

•  Definition  for  the  selected  measures  of  process  performance 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
process  performance  process  with  higher  level  management  and 
resolve  issues.  igph2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  organizational 
process  performance  process,  [gpiuj 
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GP  3.2 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  organizational  process  performance  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes  and 
process  assets,  igpiu] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  process  performance  process  that  address  quality 
and  process  performance  based  on  customer  needs  and  business 
objectives,  [gpusj 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  process  performance 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  igpus] 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Ensure  continuous  improvement  of  the  organizational  process 
performance  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization.  igpi2S] 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  organizational  process  performance  process,  [GP1211 
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ORGANIZATIONAL  INNOVATION  AND  DEPLOYMENT 

Process  Management 


Purpose 


The  purpose  of  Organizational  Innovation  and  Deployment  is  to  select 
and  deploy  incremental  and  innovative  improvements  that  measurably 
improve  the  organization's  processes  and  technologies.  The 
improvements  support  the  organization's  quality  and  process- 
performance  objectives  as  derived  from  the  organization's  business 
objectives.  [PAiei] 


Introductory  Notes 


The  Organizational  Innovation  and  Deployment  process  area  enables 
the  selection  and  deployment  of  improvements  that  can  enhance  the 
organization's  ability  to  meet  its  quality  and  process-performance 
objectives.  See  Chapter  3  for  an  explanation  of  how  “quality  and 
process-performance  objectives”  is  used  in  the  CMMI  Product  Suite. 
The  term  “improvement,”  as  used  in  this  process  area,  refers  to  all 
ideas  (proven  and  unproven)  that  would  change  the  organization’s 
processes  and  technologies  to  better  meet  the  organization’s  quality 
and  process-performance  objectives.  [pai6i.nio9] 

Quality  and  process-performance  objectives  that  this  process  area 
might  address  include  the  following:  [paisi.nioi] 

•  Improved  product  quality  (e.g.,  functionality,  performance) 

•  Increased  productivity 

•  Decreased  cycle  time 

•  Greater  customer  and  end-user  satisfaction 

•  Shorter  development  or  production  time  to  change  functionality, 

add  features,  or  adapt  to  new  technologies 

Achievement  of  these  objectives  depends  on  the  successful 
establishment  of  an  infrastructure  that  enables  and  encourages  all 
people  in  the  organization  to  propose  potential  improvements  to  the 
organization's  processes  and  technologies.  Achievement  of  these 
objectives  also  depends  on  being  able  to  effectively  evaluate  and 
deploy  proposed  improvements  to  the  organization’s  processes  and 
technologies.  All  members  of  the  organization  can  participate  in  the 
organization's  process-  and  technology-improvement  activities.  Their 
proposals  are  systematically  gathered  and  addressed.  [pai6i.nio2] 
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Pilots  are  conducted  to  evaluate  significant  changes  involving  untried, 
high-risk,  or  innovative  improvements  before  they  are  broadly  deployed. 

[PA161.N103] 


Process  and  technology  improvements  that  will  be  deployed  across  the 
organization  are  selected  from  process-  and  technology-improvement 
proposals  based  on  the  following  criteria:  [pai6i.nio4] 

•  A  quantitative  understanding  of  the  organization's  current  quality 
and  process  performance 

•  The  organization's  quality  and  process-performance  objectives 

•  Estimates  of  the  improvement  in  quality  and  process  performance 
resulting  from  deploying  the  process  and  technology  improvements 

•  Estimated  costs  of  deploying  process  and  technology 
improvements,  and  the  resources  and  funding  available  for  such 
deployment 

The  expected  benefits  added  by  the  process  and  technology 
improvements  are  weighed  against  the  cost  and  impact  to  the 
organization.  Change  and  stability  must  be  balanced  carefully.  Change 
that  is  too  great  or  too  rapid  can  overwhelm  the  organization,  destroying 
its  investment  in  organizational  learning  represented  by  organizational 
process  assets.  Rigid  stability  can  result  in  stagnation,  allowing  the 
changing  business  environment  to  erode  the  organization's  business 
position.  [PAI61.N105] 

Improvements  are  deployed,  as  appropriate,  to  new  and  ongoing 
projects.  [pai6i.nio6] 

In  this  process  area,  the  term  “process  and  technology  improvements” 
refers  to  incremental  and  innovative  improvements  to  processes  and 
also  to  process  or  product  technologies.  [PAiei.NW] 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  the  assumption  is  not  met. 

[PA161.N1 10] 


The  specific  practices  in  this  process  area  complement  and  extend 
those  found  in  the  Organizational  Process  Focus  process  area.  The 
focus  of  this  process  area  is  process  improvement  that  is  based  on  a 
quantitative  knowledge  of  the  organization’s  set  of  standard  processes 
and  technologies  and  their  expected  quality  and  performance  in 
predictable  situations.  In  the  Organizational  Process  Focus  process 
area,  no  assumptions  are  made  about  the  quantitative  basis  of 
improvement,  [paisi.nios] 
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Related  Process  Areas 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  incorporating  the  deployed  process  improvements 
into  organizational  process  assets,  [pawi.rioii 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  soliciting,  collecting,  and  handling  process- 
improvement  proposals  and  coordinating  the  deployment  of  process 
improvement  into  the  project’s  defined  processes.  [pai6i.rio2] 

Refer  to  the  Organizational  Training  process  area  for  more  information 
about  providing  updated  training  to  support  deployment  of  process  and 
technology  improvements.  [pai6i.rio3i 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance  objectives  and 
process  performance  models.  Quality  and  process-performance 
objectives  are  used  to  analyze  and  select  process-  and  technology- 
improvement  proposals  for  deployment.  Process  performance  models 
are  used  to  quantify  the  impact  and  benefits  of  innovations.  [paibi.rio4i 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results,  ipawi.rios] 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  coordinating  the  deployment  of  process  and 
technology  improvements  into  the  project’s  defined  process,  ipaibi.riob] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluations  related  to  improvement  proposals 
and  innovations,  [paibi.rios] 


Specific  Goals 


SG  1  Select  Improvements  [paibi.igioi] 


Process  and  technology  improvements  that  contribute  to  meeting  quality  and 
process-performance  objectives  are  selected. 


SG  2  Deploy  Improvements  [pai6i.igio2] 


Measurable  improvements  to  the  organization's  processes  and  technologies 
are  continually  and  systematically  deployed. 


168 


Process  Management,  Organizational  Innovation  and  Deployment 


CMMI-SW,  vl.1 
Continuous  Representation 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Select  Improvements  [paibi.igioi] 

SP  1.1-1  Collect  and  Analyze  Improvement  Proposals 
SP  1.2-1  Identify  and  Analyze  Innovations 
SP  1.3-1  Pilot  Improvements 

SP  1 .4-1  Select  Improvements  for  Deployment 

SG  2  Deploy  Improvements  [pai6i.igio2] 

SP  2.1-1  Plan  the  Deployment 

SP  2.2-1  Manage  the  Deployment 

SP  2.3-1  Measure  Improvement  Effects 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 
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GP  2.8  Monitor  and  Control  the  Process 
GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clim.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Select  Improvements 


Process  and  technology  improvements  that  contribute  to  meeting  quality  and 
process-performance  objectives  are  selected,  [pmbi.igioi] 


SP  1.1-1  Collect  and  Analyze  Improvement  Proposals 

Collect  and  analyze  process-  and  technology-improvement 
proposals.  [PA161.IG101.SP101] 

Each  process-  and  technology-improvement  proposal  must  be 
analyzed,  [pai6i.igioi.spioi.nioi] 

Simple  process  and  technology  improvements,  with  well-understood 
benefits  and  effects,  will  not  usually  undergo  detailed  evaluations. 

[PA161.IG101.SP101.N102] 


Examples  of  simple  process  and  technology  improvements  include  the  following: 

[PA161.IG101.SP101.N104] 

•  Add  an  item  to  a  peer  review  checklist. 

•  Combine  the  technical  review  and  management  review  for  suppliers  into  a  single 
technical/management  review. 


Typical  Work  Products 

1 .  Analyzed  process-  and  technology-improvement  proposals 

[PA161.IG101.SP101.W101] 

Subpractices 

1 .  Collect  process-  and  technology-improvement  proposals. 

[PA161.IG101.SP101.SubP101] 
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A  process-  and  technology-improvement  proposal  documents  proposed 
incremental  and  innovative  improvements  to  specific  processes  and  technologies. 
Managers  and  staff  in  the  organization,  as  well  as  customers,  end  users,  and 
suppliers  can  submit  process-  and  technology-improvement  proposals.  Process 
and  technology  improvements  may  be  implemented  at  the  local  level  before  being 
proposed  for  the  organization.  pAiei.iGioi.spioi.subPioi.Nioi] 


Examples  of  sources  for  process-  and  technology-improvement  proposals  include 

the  following:  [PAi6i.iGi01.sp101.subPi01.Ni02] 

•  Findings  and  recommendations  from  process  appraisals 

•  The  organization’s  quality  and  process-performance  objectives 

•  Analysis  of  data  about  customer  and  end-user  problems  as  well  as  customer  and 
end-user  satisfaction 

•  Analysis  of  data  about  project  performance  compared  to  quality  and  productivity 
objectives 

•  Analysis  of  technical  performance  measures 

•  Results  of  process  and  product  benchmarking  efforts 

•  Analysis  of  data  on  defect  causes 

•  Measured  effectiveness  of  process  activities 

•  Examples  of  process-  and  technology-improvement  proposals  that  were 
successfully  adopted  elsewhere 

•  Feedback  on  previously  submitted  process-  and  technology-improvement 
proposals 

•  Spontaneous  ideas  from  managers  and  staff 


Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process-  and  technology-improvement 
proposals.  [PAi6i.iGi01.sp101.subPi01.Ni02.Ri0i] 

2.  Analyze  the  costs  and  benefits  of  process-  and  technology- 
improvement  proposals  as  appropriate,  [paisi.igioi  spioi.subPio2] 

Process-  and  technology-improvement  proposals  that  have  a  large  cost-to-benefit 
ratio  are  rejected.  [PAi6i.iGio1.sp101.subPio2.Nioi] 

Criteria  for  evaluating  costs  and  benefits  include  the  following: 

[PA161.IG101.SP101.SubP102.N102] 

•  Contribution  toward  meeting  the  organization’s  quality  and  process-performance 
objectives 

•  Effect  on  mitigating  identified  project  and  organizational  risks 

•  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations, 
and  the  business  environment 

•  Effect  on  related  processes  and  associated  assets 
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•  Cost  of  defining  and  collecting  data  that  supports  the  measurement  and  analysis 
of  the  process-  and  technology-improvement  proposal 

•  Expected  life  span  of  the  proposal 

Process-  and  technology-improvement  proposals  that  would  not  improve  the 
organization's  processes  are  rejected.  [PAi6i.iGio1.sp101.subPio2.Nio3] 

Process  performance  models  provide  insight  into  the  effect  of  process  changes  on 
process  capability  and  performance.  [PAi6i.iGio1.sp101.subPio2.Nio4] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

[PA161.IG101.SP101.SubP102.N104.R101] 

3.  Identify  the  process-  and  technology-improvement  proposals  that 
are  innovative.  [PAi6i.iGioi.spioi.subPio3] 

Innovative  improvements  are  also  identified  and  analyzed  in  the  Identify  and 
Analyze  Innovations  specific  practice.  [PAi6i.iGi01.sp101.subPi03.Ni0i] 

Whereas  this  specific  practice  analyzes  proposals  that  have  been  passively 
collected,  the  purpose  of  the  Identify  and  Analyze  Innovations  specific  practice  is 
to  actively  search  for  and  locate  innovative  improvements.  The  search  primarily 
involves  looking  outside  the  organization.  [PAi6i.iGi01.sp101.subPi03.Ni02] 

Innovative  improvements  are  typically  identified  by  reviewing  process-  and 
technology-improvement  proposals  or  by  actively  investigating  and  monitoring 
innovations  that  are  in  use  in  other  organizations  or  are  documented  in  research 
literature.  Innovation  may  be  inspired  by  internal  improvement  objectives  or  by  the 
external  business  environment.  [PAi6i.iGio1.sp101.subPio3.Nio3] 

Innovative  improvements  are  typically  major  changes  to  the  process  that 
represent  a  break  from  the  old  way  of  doing  things  (e.g.,  changing  the  life-cycle 
model).  Innovative  improvements  may  also  include  changes  in  the  products  that 
support,  enhance,  or  automate  the  process  (for  example,  using  off-the-shelf 
products  to  support  the  process).  [PAi6i.iGio1.sp101.subPio3.Nio4] 
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Examples  of  innovative  improvements  include  the  following: 

[PA161.IG101.SP101.SubP103.N105] 

•  Advances  in  computer  and  related  hardware  products 

•  New  support  tools 

•  New  techniques,  methodologies,  processes,  or  life-cycle  models 

•  New  interface  standards 

•  New  reusable  components 

•  New  management  techniques 

•  New  quality-improvement  techniques 

•  New  process-development  and  deployment-support  tools 

4.  Identify  potential  barriers  and  risks  to  deploying  each  process-  and 
technology-improvement  proposal.  [pai6i.igioi  spioi.subPio4] 

Examples  of  barriers  to  deploying  process  and  technology  improvements  include 
the  following:  [PAi6i.iGi01.sp101.subPi04.Ni0i] 

•  Turf  guarding  and  parochial  perspectives 

•  Unclear  or  weak  business  rationale 

•  Lack  of  short-term  benefits  and  visible  successes 

•  Unclear  picture  of  what  is  expected  from  everyone 

•  Too  many  changes  at  the  same  time 

•  Lack  of  involvement  and  support  of  relevant  stakeholders 

Examples  of  risk  factors  that  affect  the  deployment  of  process  and  technology 
improvements  include  the  following:  [PAi6i.iGio1.sp101.subPio4.Nio2] 

•  Compatibility  of  the  improvement  with  existing  processes,  values,  and  skills  of 
potential  end  users 

•  Complexity  of  the  improvement 

•  Difficulty  implementing  the  improvement 

•  Ability  to  demonstrate  the  value  of  the  improvement  before  widespread 
deployment 

•  Justification  for  large,  up-front  investments  in  areas  such  as  tools  and  training 

•  Inability  to  overcome  “technology  drag”  where  the  current  implementation  is  used 
successfully  by  a  large  and  mature  installed  base  of  end  users 

5.  Estimate  the  cost,  effort,  and  schedule  required  for  deploying  each 
process-  and  technology-improvement  proposal. 

[PA161.IG101.SP101.SubP105] 

6.  Select  the  process-  and  technology-improvement  proposals  to  be 
piloted  before  broadscale  deployment.  [PAi6i.iGioi.spioi.subPio6] 
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Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted.  [PAiei.iGioi.spioi.subPioe.Nioi] 

7.  Document  the  results  of  the  evaluation  of  each  process-  and 
technology-improvement  proposal.  [PAi6i.iGioi.spioi.subPio7] 

8.  Monitor  the  status  of  each  process-  and  technology-improvement 

prOpOSal.  [PA161  .IG101.SP101  .SubP108] 


SP  1.2-1  Identify  and  Analyze  Innovations 

Identify  and  analyze  innovative  improvements  that  could  increase 
the  organization’s  quality  and  process  performance,  [paibi.igioi.spi 021 


The  specific  practice  Collect  and  Analyze  Improvement  Proposals 
analyzed  proposals  that  were  passively  collected.  The  purpose  of  this 
specific  practice  is  to  actively  search  for,  locate,  and  analyze  innovative 
improvements.  This  search  primarily  involves  looking  outside  the 
organization,  [pai6ugioi.spio2.nioi] 

Typical  Work  Products 

1.  Candidate  innovative  improvements  [pai6i.igioi.spio2.wioi] 

2.  Analysis  of  proposed  innovative  improvements  [pai6i.igioi.spio2.wio2] 

Subpractices 

1 .  Analyze  the  organization's  set  of  standard  processes  to  determine 
areas  where  innovative  improvements  would  be  most  helpful. 

[PA161.IG101.SP102.SubP101] 

These  analyses  are  performed  to  determine  which  subprocesses  are  critical  to 
achieving  the  organization's  quality  and  process-performance  objectives  and 
which  ones  are  good  candidates  to  be  improved.  [PAi6i.iGi01.sp102.subPi01.Ni0i] 

2.  Investigate  innovative  improvements  that  may  improve  the 
organization's  set  of  standard  processes,  [paisi.igioi  spio2.subPio2] 

Investigating  innovative  improvements  involves  the  following: 

[PAi6i.iGi01.sp102.subPi02.Ni0i] 

•  Systematically  maintaining  awareness  of  leading  relevant  technical  work  and 
technology  trends 

•  Periodically  searching  for  commercially  available  innovative  improvements 

•  Collecting  proposals  for  innovative  improvements  from  the  projects  and  the 
organization 

•  Systematically  reviewing  processes  and  technologies  used  externally  and 
comparing  them  to  those  used  within  the  organization 

•  Identifying  areas  where  innovative  improvements  have  been  used  successfully, 
and  reviewing  data  and  documentation  of  experience  using  these  improvements 


174 


Process  Management,  Organizational  Innovation  and  Deployment 


CMMI-SW,  vl.1 
Continuous  Representation 


3.  Analyze  potential  innovative  improvements  to  understand  their 
effects  on  process  elements  and  predict  their  influence  on  the 

process.  [PA161.IG101.SP102.SubP103] 

Process  performance  models  can  provide  a  basis  for  analyzing  possible  effects  of 
changes  to  process  elements.  [PAi6i.iGi01.sp102.subPi03.Ni0i] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

[PA161.IG101.SP102.SubP103.N101.R101] 

4.  Analyze  the  costs  and  benefits  of  potential  innovative 
improvements.  [PAiei.iGioi.spio2.subPio4] 

Innovative  improvements  that  have  a  very  large  cost-to-benefit  ratio  are  rejected. 

[PA161.IG101.SP102.SubP104.N101] 

5.  Create  process-  and  technology-improvement  proposals  for  those 
innovative  improvements  that  would  result  in  improving  the 
organization's  processes  or  technologies.  [PAi6i.iGioi.spio2.subPio5] 

6.  Select  the  innovative  improvements  to  be  piloted  before  broadscale 
deployment.  [PAi6i.iGioi.spio2.subPio6] 

Since  innovations,  by  definition,  usually  represent  a  major  change,  most 
innovative  improvements  will  be  piloted.  [PAi6i.iGi01.sp102.subPi06.Ni0i] 

7.  Document  the  results  of  the  evaluations  of  innovative 
improvements.  [PAi6i.iGioi.spio2.subPio7] 


SP  1.3-1  Pilot  Improvements 

Pilot  process  and  technology  improvements  to  select  which  ones 
to  implement.  [pai6i.igioi.spio3] 


Pilots  are  performed  to  assess  new  and  unproven  major  changes 
before  they  are  broadly  deployed,  as  appropriate,  [pai6i.igioi.spio3.nioi] 

The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects),  [pai6i.igioi.spio3.nio2] 

Typical  Work  Products 

1 .  Pilot  evaluation  reports  [pai6i.igioi.spio3.wioi] 

2.  Documented  lessons  learned  from  pilots  [pai6i.igioi.spio3.wio2] 
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Subpractices 

1 .  Plan  the  pilots.  [PAi6i.iGioi.spio3.subPioi] 

When  planning  pilots,  it  is  critical  to  define  criteria  to  be  used  for  evaluating  pilot 

reSUltS.  [PA161.IG101.SP103.SubP101.N101] 

2.  Review  and  get  relevant  stakeholder  agreement  on  the  plans  for 

the  pilots.  [PA161.IG101.SP1 03. SubPI 02] 

3.  Consult  with  and  assist  the  people  performing  the  pilots. 

[PA161.IG101.SP103.SubP103] 

4.  Perform  each  pilot  in  an  environment  that  is  characteristic  of  the 
environment  present  in  a  broadscale  deployment. 

[PA161.IG101.SP103.SubP104] 

5.  Track  the  pilots  against  their  plans.  [PAi6i.iGioi.spio3.subPios] 

6.  Review  and  document  the  results  of  pilots.  [PAiei.iGioi.spio3.subPio6] 
Reviewing  and  documenting  the  results  of  pilots  usually  involves  the  following: 

[PA161.IG101.SP103.SubP106.N101] 

•  Deciding  whether  to  terminate  the  pilot,  re-plan  and  continue  the  pilot,  or  proceed 
with  deploying  the  process  and  technology  improvement 

•  Updating  the  disposition  of  process-  and  technology-improvement  proposals 
associated  with  the  pilot 

•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals  as  appropriate 

•  Identifying  and  documenting  lessons  learned  and  problems  encountered  during 
the  pilot 


SP  1.4-1  Select  Improvements  for  Deployment 

Select  process-  and  technology-improvement  proposals  for 
deployment  across  the  organization.  [pai6i.igioi.spio4] 

Selection  of  process-  and  technology-improvement  proposals  for 
deployment  across  the  organization  is  based  on  quantifiable  criteria 
derived  from  the  organization’s  quality  and  process-performance 

objectives.  [PA161.IG101.SP104.N101] 

Typical  Work  Products 

1 .  Process-  and  technology-improvement  proposals  selected  for 
deployment  [pai6i.igioi.spio4.wioi] 

Subpractices 

1 .  Prioritize  the  candidate  process  and  technology  improvements  for 
deployment.  [PAi6i.iGioi.spio4.subPioi] 
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Priority  is  based  on  an  evaluation  of  the  estimated  cost-to-benefit  ratio  with  regard 
to  the  quality  and  process-performance  objectives.  [PAi6i.iGioi.spio4.subPioi.Nioi] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  quality  and  process-performance 

objectives.  [PA161.IG101.SP104.SubP101.N101.R101] 

2.  Select  the  process  and  technology  improvements  to  be  deployed. 

[PA161.IG101.SP104.SubP102] 

The  selection  of  the  process  improvements  is  based  on  their  priorities  and  the 
available  resources.  [PAi6i.iGi01.sp104.subPi02.Ni0i] 

3.  Determine  how  each  process  and  technology  improvement  will  be 
deployed.  [PAiei.iGioi.spio4.subPio3] 

Examples  of  how  the  process  and  technology  improvements  may  be  deployed 
include  incorporating  these  improvements  into  the  following: 

[PA161.IG101.SP104.SubP103.N101] 

•  Organizational  process  assets 

•  All  or  a  subset  of  the  organization's  product  families 

•  All  or  a  subset  of  the  organization's  projects 

•  All  or  a  subset  of  the  organizational  groups 

4.  Document  the  results  of  the  selection  process.  [PAi6i.iGioi.spio4.subPio4] 
The  results  of  the  selection  process  usually  include  the  following: 

[PA161.IG101.SP104.SubP104.N101] 

•  The  selection  criteria 

•  The  disposition  of  each  proposal 

•  The  rationale  for  the  disposition  of  each  proposal 

•  The  assets  to  be  changed  for  each  selected  proposal 

SG  2  Deploy  Improvements 

Measurable  improvements  to  the  organization's  processes  and  technologies 
are  continually  and  systematically  deployed.  [pai6i.igio2] 


SP  2.1-1  Plan  the  Deployment 

Establish  and  maintain  the  plans  for  deploying  the  selected 
process  and  technology  improvements,  ipai6i.igio2.spwi] 
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The  plans  for  deploying  each  process  and  technology  improvement 
may  be  included  in  the  organization's  plan  for  organizational  innovation 
and  deployment  or  they  may  be  documented  separately. 

[PA161.IG102.SP101.N101] 


This  specific  practice  plans  the  deployment  of  individual  process  and 
technology  improvements.  The  Plan  the  Process  generic  practice 
addresses  comprehensive  planning  that  covers  the  specific  practices  in 
this  process  area,  [pai6i.igio2.spioi.nio2] 

Typical  Work  Products 

1 .  Deployment  plan  for  selected  process  and  technology 
improvements  [pai6i.igio2.spioi.wioi] 

Subpractices 

1 .  Determine  how  each  process  and  technology  improvement  must 
be  adjusted  for  organization-wide  deployment.  [PAi6i.iGio2.spioi.subPioi] 

Process  and  technology  improvements  proposed  within  a  limited  context  (e.g.,  for 
a  single  project)  might  have  to  be  modified  to  work  across  the  organization. 

[PA161.IG102.SP101.SubP101.N101] 

2.  Determine  the  changes  necessary  to  deploy  each  process  and 
technology  improvement.  [PAiei.iGio2.spioi.subPio2] 


Examples  of  changes  needed  to  deploy  a  process  and  technology  improvement 
include  the  following:  [PAi6i.iGi02.sp101.subPi02.Ni0i] 

•  Process  descriptions,  standards,  and  procedures 

•  Development  environments 

•  Education  and  training 

•  Skills 

•  Existing  commitments 

•  Existing  activities 

•  Continuing  support  to  end  users 

•  Organizational  culture  and  characteristics 

3.  Identify  strategies  to  address  potential  barriers  to  deploying  each 
process  and  technology  improvement.  [PAi6i.iGio2.spioi.subPio3] 

4.  Establish  measures  and  objectives  for  determining  the  value  of 
each  process  and  technology  improvement  with  respect  to  the 
organization’s  quality  and  process-performance  objectives. 

[PA161.IG102.SP101.SubP104] 
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Examples  of  measures  for  determining  the  value  of  a  process  and  technology 
improvement  include  the  following:  [PAi6i.iGio2.sp101.subPio4.Nioi] 

•  Return  on  investment 

•  Time  to  recover  the  cost  of  the  process  or  technology  improvement 

•  Measured  improvement  in  the  project’s  or  organization's  process  performance 

•  Number  and  types  of  project  and  organizational  risks  mitigated  by  the  process  or 
technology  improvement 

•  Ability  to  respond  quickly  to  changes  in  project  requirements,  market  situations, 
and  the  business  environment 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

[PA161.IG102.SP101.SubP104.N101.R101] 

5.  Document  the  plan  for  deploying  each  process  and  technology 
improvement.  [PAi6i.iGio2.spioi.subPio5] 

6.  Review  and  get  agreement  with  relevant  stakeholders  on  the  plan 
for  deploying  each  process  and  technology  improvement. 

[PA161.IG102.SP101.SubP106] 

7.  Revise  the  plan  for  deploying  each  process  and  technology 
improvement  as  necessary.  [PAi6i.iGio2.spioi.subPio7] 


SP  2.2-1  Manage  the  Deployment 

Manage  the  deployment  of  the  selected  process  and  technology 
improvements,  [pai6i.igio2.spi 02] 


The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Implement  the  Action  Proposals  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects).  The  primary  difference  is  that  in  the  Causal  Analysis 
and  Resolution  process  area,  planning  is  done  to  manage  the  removal 
of  the  root  causes  of  defects  or  problems  from  the  project’s  defined 
processes.  In  the  Organizational  Innovation  and  Deployment  process 
area,  planning  is  done  to  manage  the  deployment  of  improvements  to 
the  organization’s  processes  and  technologies  that  can  be  quantified 
against  the  organization’s  business  objectives,  [pai6i.igio2.spio2.nioi] 

Typical  Work  Products 

1 .  Updated  training  materials  (to  reflect  deployed  process  and 
technology  improvements)  [PAi6i.iGi02.sp102.w10i] 
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2.  Documented  results  of  process-  and  technology-improvement 
deployment  activities  [PAi6i.iGi02.sp102.w102] 

3.  Revised  process-  and  technology-improvement  measures, 
objectives,  priorities,  and  deployment  plans  [pai6i.igio2.spio2.wio3] 

Subpractices 

1 .  Monitor  the  deployment  of  the  process  and  technology 
improvements  using  the  deployment  plan.  [PAi6i.iG«>2.spio2.subPioi] 

2.  Coordinate  the  deployment  of  process  and  technology 
improvements  across  the  organization.  [PAi6i.iGio2.spio2.subPio2] 

Coordinating  deployment  includes  the  following  activities:  [PAi6i.iGi02.sp102.subPi02.Ni0i] 

•  Coordinating  the  activities  of  projects,  support  groups,  and  organizational  groups 
for  each  process  and  technology  improvement 

•  Coordinating  the  activities  for  deploying  related  process  and  technology 
improvements 

3.  Quickly  deploy  process  and  technology  improvements  in  a 
controlled  and  disciplined  manner,  as  appropriate. 

[PA161.IG102.SP102.SubP103] 


Examples  of  methods  for  quickly  deploying  process  and  technology  improvements 

include  the  following:  [PAi6i.iGi02.sp102.subPi03.Ni0i] 

•  Using  red-lines,  process  change  notices,  or  other  controlled  process 
documentation  as  interim  process  descriptions 

•  Deploying  process  and  technology  improvements  incrementally,  rather  than  as  a 
single  deployment 

•  Providing  comprehensive  consulting  to  early  adopters  of  the  process  and 
technology  improvement  in  lieu  of  revised  formal  training 


4.  Incorporate  the  process  and  technology  improvements  into 
organizational  process  assets,  as  appropriate.  [PAi6i.iGio2.spio2.subPio4] 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  organizational  process  assets. 

[PA161.IG102.SP102.SubP104.R101] 

5.  Coordinate  the  deployment  of  the  process  and  technology 
improvements  into  the  projects'  defined  processes  as  appropriate. 

[PA161.IG102.SP102.SubP105] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  deploying  organizational  process  assets. 

[PA161.IG102.SP102.SubP105.R101] 

6.  Provide  consulting,  as  appropriate,  to  support  deployment  of  the 
process  and  technology  improvements.  [PAiei.iGio2.spio2.subPio6] 


180 


Process  Management,  Organizational  Innovation  and  Deployment 


CMMI-SW,  vl.1 
Continuous  Representation 


7.  Provide  updated  training  materials  to  reflect  the  improvements  to 
the  organizational  process  assets.  [PAi6i.iGio2.spio2.subPio7] 

Refer  to  the  Organizational  Training  process  area  for  more 
information  about  training  materials.  [PM6i.iGi02.sp102.subPi07.Ri0i] 

8.  Confirm  that  the  deployment  of  all  process  and  technology 
improvements  is  completed.  [PAiei.iGw.spw.subPiosi 

9.  Determine  whether  the  ability  of  the  defined  process  to  meet 
quality  and  process-performance  objectives  is  adversely  affected 
by  the  process  and  technology  improvement,  and  take  corrective 
action  as  necessary.  [PAi6i.iGio2.spio2.subPio9] 

Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  quantitatively  managing  the  project’s 
defined  process  to  achieve  the  project’s  established  quality  and 
process-performance  objectives.  [PAw1.iGw2.spw2.subPio9.Rioi] 

10.  Document  and  review  the  results  of  process-  and  technology- 
improvement  deployment.  [PAi6i.iGio2.spio2.subPiio] 

Documenting  and  reviewing  the  results  includes  the  following: 

[PAi6i.iGio2.sp102.subPi10.Nioi] 

•  Identifying  and  documenting  lessons  learned 

•  Identifying  and  documenting  new  process-  and  technology-improvement 
proposals 

•  Revising  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 


SP  2.3-1  Measure  Improvement  Effects 

Measure  the  effects  of  the  deployed  process  and  technology 
improvements,  ipai6i.igw2.spw3] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results. 

[PA161.IG102.SPW3.RW1] 


The  implementation  of  this  specific  practice  may  overlap  with  the 
implementation  of  the  Evaluate  the  Effect  of  Changes  specific  practice 
in  the  Causal  Analysis  and  Resolution  process  area  (e.g.,  when  causal 
analysis  and  resolution  is  implemented  organizationally  or  across 
multiple  projects),  [pai6i.igio2.spio3.nioi] 
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Typical  Work  Products 

1 .  Documented  measures  of  the  effects  resulting  from  the  deployed 
process  and  technology  improvements  [pai6i.igio2.spio3.wioi] 

Subpractices 

1 .  Measure  the  actual  cost,  effort,  and  schedule  for  deploying  each 
process  and  technology  improvement.  [PAi6i.iGio2.spio3.subPioi] 

2.  Measure  the  value  of  each  process  and  technology  improvement. 

[PA161.IG102.SP103.SubP102] 

3.  Measure  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives.  [PAi6i.iGio2.spio3.subPio3] 

4.  Analyze  the  progress  toward  achieving  the  organization's  quality 
and  process-performance  objectives  and  take  corrective  action  as 
needed.  [PAi6i.iGio2.spio3.subPio4] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  analyses. 

[PA161.IG102.SP103.SubP104.R101] 

5.  Store  the  measures  in  the  organization’s  measurement  repository. 

[PA161.IG102.SP103.SubP105] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  organizational  innovation  and 
deployment  process  to  develop  work  products  and  provide 
services  to  achieve  the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 
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GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  organizational  innovation  and  deployment  process. 

[GP103] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  and 
deploying  process  and  technology  improvements  that  contribute  to 
meeting  quality  and  process-performance  objectives,  [paibi .elioij 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  organizational 
innovation  and  deployment  process,  igpkm] 


Elaboration: 

This  plan  for  performing  the  organizational  innovation  and  deployment 
process  differs  from  the  deployment  plans  described  in  a  specific 
practice  in  this  process  area.  The  plan  called  for  in  this  generic  practice 
would  address  the  comprehensive  planning  for  all  of  the  specific 
practices  in  this  process  area,  from  collecting  and  analyzing 
improvement  proposals  all  the  way  through  to  the  measurement  of 
improvement  effects.  In  contrast,  the  deployment  plans  called  for  in  the 
specific  practice  would  address  the  planning  needed  for  the  deployment 
of  individual  process  and  technology  improvements,  [paibi  elho] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  organizational 
innovation  and  deployment  process,  developing  the  work 
products,  and  providing  the  services  of  the  process,  [gpiosj 

Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pai6i.elio2] 

•  Simulation  packages 

•  Prototyping  tools 

•  Statistical  packages 

•  Dynamic  systems  modeling 

•  Subscriptions  to  online  technology  databases 

•  Process  modeling  tools 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
organizational  innovation  and  deployment  process,  [gpiob] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  organizational 
innovation  and  deployment  process  as  needed,  [gpioji 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pai6i.elio3] 

•  Planning,  designing,  and  conducting  pilots 

•  Cost/benefit  analysis 

•  Technology  transition 

•  Change  management 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  organizational  innovation 
and  deployment  process  under  appropriate  levels  of  configuration 
management,  [GPmj 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai6i.elih] 

•  Documented  lessons  learned  from  pilots 

•  Revised  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 

•  Updated  training  material 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  organizational 
innovation  and  deployment  process  as  planned.  igpi24] 
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Examples  of  activities  for  stakeholder  involvement  include:  [paisi.elim] 

•  Reviewing  process-  and  technology-improvement  proposals  that  may  have  major 
impacts  on  process  performance  or  on  customer  and  end-user  satisfaction 

•  Providing  feedback  to  the  organization  on  the  status  and  results  of  the  process- 
and  technology-improvement  deployment  activities 


The  feedback  typically  involves:  [pai6i.elh5] 

•  Informing  the  people  who  submit  process-  and  technology- 
improvement  proposals  about  the  disposition  of  their  proposals 

•  Regularly  informing  relevant  stakeholders  about  the  plans  and 
status  for  selecting  and  deploying  process  and  technology 
improvements 

•  Preparing  and  distributing  a  summary  of  process-  and  technology- 
improvement  selection  and  deployment  activities 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  organizational  innovation  and  deployment 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action,  ig phoi 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA161.EL106] 

•  Change  in  quality 

•  Change  in  process  performance 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  organizational  innovation 
and  deployment  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance,  igpu3i 


Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai6i.elio9] 

•  Selecting  improvements 

•  Deploying  improvements 
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Examples  of  work  products  reviewed  include  the  following:  [pai6i.elh3] 

•  Deployment  plans 

•  Revised  process-  and  technology-improvement  measures,  objectives,  priorities, 
and  deployment  plans 

•  Updated  training  material 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  organizational 
innovation  and  deployment  process  with  higher  level  management 
and  resolve  issues,  ig pmi 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  organizational 
innovation  and  deployment  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  organizational  innovation  and  deployment  process  to  support 
the  future  use  and  improvement  of  the  organization’s  processes 
and  process  assets.  [gph7i 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
organizational  innovation  and  deployment  process  that  address 
quality  and  process  performance  based  on  customer  needs  and 
business  objectives,  [gphsi 
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GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  organizational  innovation  and 
deployment  process  to  achieve  the  established  quantitative  quality 
and  process-performance  objectives,  [gpusi 


GG  5  Institutionalize  an  Optimizing  Process 


The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  organizational  innovation 
and  deployment  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization.  igpi2S] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  organizational  innovation  and  deployment  process.  [GPi2ii 
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PROJECT  MANAGEMENT 


The  following  section  contains  all  of  the  process  areas  that  belong  to 
the  Project  Management  process  area  category.  The  Project 
Management  process  areas  of  CMMI  are  as  follows:  [FM105.T102] 

•  Project  Planning 

•  Project  Monitoring  and  Control 

•  Supplier  Agreement  Management 

•  Integrated  Project  Management 

•  Risk  Management 

•  Quantitative  Project  Management 

See  Chapter  5  for  more  information  about  the  Project  Management 
process  areas  and  how  they  interact,  [fmios.tkmi 
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PROJECT  PLANNING 

Project  Management 


Purpose 


The  purpose  of  Project  Planning  is  to  establish  and  maintain  plans  that 
define  project  activities.  [pai63] 


Introductory  Notes 


The  Project  Planning  process  area  involves  the  following:  [pai63.nioi] 

•  Developing  the  project  plan 

•  Interacting  with  stakeholders  appropriately 

•  Getting  commitment  to  the  plan 

•  Maintaining  the  plan 

Planning  begins  with  requirements  that  define  the  product  and  project. 

[PA163.N102] 


Planning  includes  estimating  the  attributes  of  the  work  products  and 
tasks,  determining  the  resources  needed,  negotiating  commitments, 
producing  a  schedule,  and  identifying  and  analyzing  project  risks. 
Iterating  through  these  activities  may  be  necessary  to  establish  the 
project  plan.  The  project  plan  provides  the  basis  for  performing  and 
controlling  the  project’s  activities  that  address  the  commitments  with  the 
project’s  customer.  [pai63.nio3] 

The  project  plan  will  usually  need  to  be  revised  as  the  project 
progresses  to  address  changes  in  requirements  and  commitments, 
inaccurate  estimates,  corrective  actions,  and  process  changes.  Specific 
practices  describing  both  planning  and  re-planning  are  contained  in  this 
process  area.  [pai63.nio4] 


The  term  “project  plan”  is  used  throughout  the  generic  and  specific 
practices  in  this  process  area  to  refer  to  the  overall  plan  for  controlling 
the  project.  [pai63.nio5] 
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Refer  to  the  Requirements  Development  process  area  for  more 
information  about  developing  requirements  that  define  the  product  and 
product  components.  Product  and  product-component  requirements 
and  changes  to  those  requirements  serve  as  a  basis  for  planning  and 
re-planning.  [paw3.rioii 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements  needed  for  planning  and  re¬ 
planning.  [PA163.R102] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  managing  risks.  ipai63.rio3] 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  product  and  product-component 

SOlUtiOnS.  [PA163.R104] 


Specific  Goals 

SG  1  Establish  Estimates  [pai63igioi] 

Estimates  of  project  planning  parameters  are  established  and  maintained. 

SG  2  Develop  a  Project  Plan  [PA163.IG102] 

A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 
project. 

SG  3  Obtain  Commitment  to  the  Plan  [pai63  igio3] 

Commitments  to  the  project  plan  are  established  and  maintained. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 
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GG  3  Institutionalize  a  Defined  Process  [clim.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Establish  Estimates  [pai63.igioi] 

SP  1.1-1  Estimate  the  Scope  of  the  Project 

SP  1 .2-1  Establish  Estimates  of  Work  Product  and  Task  Attributes 

SP  1 .3-1  Define  Project  Life  Cycle 

SP  1 .4-1  Determine  Estimates  of  Effort  and  Cost 

SG  2  Develop  a  Project  Plan  [PA163.IG102] 

SP  2.1-1  Establish  the  Budget  and  Schedule 

SP  2.2-1  Identify  Project  Risks 

SP  2.3-1  Plan  for  Data  Management 

SP  2.4-1  Plan  for  Project  Resources 

SP  2.5-1  Plan  for  Needed  Knowledge  and  Skills 

SP  2.6-1  Plan  Stakeholder  Involvement 

SP  2.7-1  Establish  the  Project  Plan 

SG  3  Obtain  Commitment  to  the  Plan  [pai63.igio3] 

SP  3.1-1  Review  Plans  that  Affect  the  Project 
SP  3.2-1  Reconcile  Work  and  Resource  Levels 

SP  3.3-1  Obtain  Plan  Commitment 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

GP3.1  Establish  a  Defined  Process 
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GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Establish  Estimates 


Estimates  of  project  planning  parameters  are  established  and  maintained. 

[PA163.IG101] 

Project  planning  parameters  include  all  information  needed  by  the 
project  to  perform  the  necessary  planning,  organizing,  staffing, 
directing,  coordinating,  reporting,  and  budgeting,  [pai63.igioi.nioi] 

Estimates  of  planning  parameters  should  have  a  sound  basis  to  provide 
confidence  that  any  plans  based  on  these  estimates  are  capable  of 
supporting  project  objectives,  ipai63.igioi.nio2] 

Factors  that  are  typically  considered  when  estimating  these  parameters 
include  the  following:  [pai63.igioi.nio3] 

•  Project  requirements,  including  the  product  requirements,  the 
requirements  imposed  by  the  organization,  the  requirements 
imposed  by  the  customer,  and  other  requirements  that  impact  the 
project 

•  Scope  of  the  project 

•  Identified  tasks  and  work  products 

•  Technical  approach 

•  Selected  project  life-cycle  model  (e.g.,  waterfall,  incremental, 
spiral,  etc.) 

•  Attributes  of  the  work  products  and  tasks  (e.g.,  size  or  complexity) 

•  Schedule 

•  Models  or  historical  data  for  converting  the  attributes  of  the  work 
products  and  tasks  into  labor  hours  and  cost 

•  Methodology  (models,  data,  algorithms)  used  to  determine  needed 
material,  skills,  labor  hours,  and  cost 

Documenting  the  estimating  rationale  and  supporting  data  is  needed  for 
stakeholders’  review  and  commitment  to  the  plan  and  for  maintenance 
of  the  plan  as  the  project  progresses,  [pai63.igioi.nio4] 
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SP  1.1-1  Estimate  the  Scope  of  the  Project 

Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate 
the  scope  of  the  project,  [pm63.igioi.spwi] 


The  WBS  evolves  with  the  project.  Initially  a  top-level  WBS  can  serve  to 
structure  the  initial  estimating.  The  development  of  a  WBS  divides  the 
overall  project  into  an  interconnected  set  of  manageable  components. 
The  WBS  is  typically  a  product-oriented  structure  that  provides  a 
scheme  for  identifying  and  organizing  the  logical  units  of  work  to  be 
managed,  which  are  called  “work  packages.”  The  WBS  provides  a 
reference  and  organizational  mechanism  for  assigning  effort,  schedule, 
and  responsibility  and  is  used  as  the  underlying  framework  to  plan, 
organize,  and  control  the  work  done  on  the  project,  [pai63.igioi.spioi.nioi] 

Typical  Work  Products 

1.  Task  descriptions  [pai63.igioi.spioi.wioi] 

2.  Work  package  descriptions  [pai63.igioi.spioi.wio2] 

3.  WBS  [PA163.IG101.SP101.W103] 

Subpractices 

1 .  Develop  a  WBS  based  on  the  product  architecture. 

[PA163.IG101.SP101.SubP101] 

The  WBS  provides  a  scheme  for  organizing  the  project’s  work  around  the 
products  that  the  work  supports.  The  WBS  should  permit  the  identification  of  the 
following  items:  [PAi63.iGioi.spioi.subPioi.Nioi] 

•  Identified  risks  and  their  mitigation  tasks 

•  Tasks  for  deliverables  and  supporting  activities 

•  Tasks  for  skill  and  knowledge  acquisition 

•  Tasks  for  development  of  needed  support  plans,  such  as  configuration 
management,  quality  assurance,  and  verification  plans 

•  Tasks  for  integration  and  management  of  non-developmental  items 

2.  Identify  the  work  packages  in  sufficient  detail  to  specify  estimates 
of  project  tasks,  responsibilities,  and  schedule.  [PAi63.iGioi.spioi.subPio2] 

The  top-level  WBS  is  intended  to  help  in  gauging  the  project  work  effort  in  terms 
of  tasks  and  organizational  roles  and  responsibilities.  The  amount  of  detail  in  the 
WBS  at  this  more  detailed  level  helps  in  developing  realistic  schedules,  thereby 
minimizing  the  need  for  management  reserve.  [PAie3.iGi01.sp101.subPi02.Ni0i] 

3.  Identify  work  products  (or  components  of  work  products)  that  will 
be  externally  acquired.  [PAi63.iGioi.spioi.subPio3] 
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Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  work  products  from  sources 
external  to  the  project.  [PM63.iGioi.spioi.subPio3.Rioi] 

4.  Identify  work  products  that  will  be  reused.  [PAi63.iGioi.spioi.subPio4] 


SP  1.2-1  Establish  Estimates  of  Work  Product  and  Task  Attributes 

Establish  and  maintain  estimates  of  the  attributes  of  the  work 
products  and  tasks,  [pai63.igwi.spi 02] 

Size  is  the  primary  input  to  many  models  used  to  estimate  effort,  cost, 
and  schedule.  The  models  may  also  be  based  on  inputs  such  as 
connectivity,  complexity,  and  structure,  [pai63.igioi.spio2.nio2] 

Examples  of  types  of  work  products  for  which  size  estimates  are  made  include  the 

following:  [PA163.IG101.SP102.N103] 

•  Deliverable  and  nondeliverable  work  products 

•  Documents 

•  Operational  and  support  software 

Examples  of  size  measures  include  the  following:  [pai63.igioi.spio2.nio4] 

•  Number  of  functions 

•  Function  points 

•  Source  lines  of  code 

•  Number  of  classes  and  objects 

•  Number  of  requirements 

•  Number  of  interfaces 

•  Number  of  pages 

•  Number  of  inputs  and  outputs 

•  Number  of  technical  risk  items 

•  Volume  of  data 

The  estimates  should  be  consistent  with  project  requirements  to 
determine  the  project’s  effort,  cost,  and  schedule.  A  relative  level  of 
difficulty  or  complexity  should  be  assigned  for  each  size  attribute. 

[PA163.IG101.SP102.N101] 

Typical  Work  Products 

1.  Technical  approach  [pai63.igioi.spio2.wioi] 

2.  Size  and  complexity  of  tasks  and  work  products  [pai63.igioi.spio2.wio2] 
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3.  Estimating  models  [pai63.igioi.spio2.wio3] 

4.  Attribute  estimates  [pai63.igioi.spio2.wio4] 

Subpractices 

1 .  Determine  the  technical  approach  for  the  project. 

[PA163.IG101.SP102.SubP101] 

The  technical  approach  defines  a  top-level  strategy  for  development  of  the 
products.  It  includes  decisions  on  architectural  features,  such  as  distributed  or 
client  server;  state-of-the-art  or  established  technologies  to  be  applied,  such  as 
robotics,  composite  materials,  or  artificial  intelligence;  and  breadth  of  the 
functionality  expected  in  the  final  products,  such  as  safety,  security,  and 
ergonomics.  [PAi63.iGio1.sp102.subPio1.Nioi] 

2.  Use  appropriate  methods  to  determine  the  attributes  of  the  work 
products  and  tasks  that  will  be  used  to  estimate  the  resource 
requirements.  [PAi63.iGioi.spio2.subPio2] 

Methods  for  determining  size  and  complexity  should  be  based  on  validated 
models  or  historical  data.  [PAi63.iGio1.sp102.subPio2.Nioi] 

The  methods  for  determining  attributes  evolve  as  our  understanding  of  the 
relationship  of  product  characteristics  to  attributes  increases. 

[PA163.IG101.SP102.SubP102.N102] 


Examples  of  current  methods  include  the  following:  [PAi63.iGio1.sp102.subPio2.Nio3] 

•  Number  of  logic  gates  for  integrated  circuit  design 

•  Lines  of  code  or  function  points  for  software 

•  Number/complexity  of  requirements  for  systems  engineering 

•  Number  of  square  feet  for  standard-specified  residential  homes 

3.  Estimate  the  attributes  of  the  work  products  and  tasks. 

[PA163.IG101.SP102.SubP103] 

4.  Estimate,  as  appropriate,  the  labor,  machinery,  materials,  and 
methods  that  will  be  required  by  the  project.  [PAi63.iGioi.spio2.subPio4] 


SP  1.3-1  Define  Project  Life  Cycle 

Define  the  project  life-cycle  phases  upon  which  to  scope  the 
planning  effort.  [paib3.igioi.spi<>3] 
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The  determination  of  a  project’s  life-cycle  phases  provides  for  planned 
periods  of  evaluation  and  decision  making.  These  are  normally  defined 
to  support  logical  decision  points  at  which  significant  commitments  are 
made  concerning  resources  and  technical  approach.  Such  points 
provide  planned  events  at  which  project  course  corrections  and 
determinations  of  future  scope  and  cost  can  be  made,  [pai63.igioi.spio3.nioi] 

For  Software  Engineering 

The  determination  of  project  phases  for  software  typically 
includes  selection  and  refinement  of  a  software  development 
model  to  address  interdependencies  and  appropriate 
sequencing  of  software  project  activities. 

[PA163.IG101  .SP103.N101  .AMP101] 


The  project  life  cycle  consists  of  phases  that  need  to  be  defined 
depending  on  the  scope  of  requirements,  the  estimates  for  project 
resources,  and  the  nature  of  the  project.  Larger  projects  may  contain 
multiple  phases,  such  as  concept  exploration,  development,  production, 
operations,  and  disposal.  Within  these  phases,  subphases  may  be 
needed.  A  development  phase  may  include  subphases  such  as 
requirements  analysis,  design,  fabrication,  integration,  and  verification. 
Depending  on  the  strategy  for  development,  there  may  be  intermediate 
phases  for  the  creation  of  prototypes,  increments  of  capability,  or  spiral 

model  cycles.  [PA163.IG101.SP103.N102] 

Understanding  the  project  life  cycle  is  crucial  in  determining  the  scope 
of  the  planning  effort  and  the  timing  of  the  initial  planning,  as  well  as  the 
timing  and  criteria  (critical  milestones)  for  re-planning,  [pai63.igioi.spio3.nio3] 

Typical  Work  Products 

1.  Project  life-cycle  phases  [pai63.igioi  spio3.wioi] 


SP  1.4-1  Determine  Estimates  of  Effort  and  Cost 

Estimate  the  project  effort  and  cost  for  the  work  products  and 
tasks  based  on  estimation  rationale,  [pai63.igioi.spw4] 


Estimates  of  effort  and  cost  are  generally  based  on  the  results  of 
analysis  using  models  or  historical  data  applied  to  size,  activities,  and 
other  planning  parameters.  Confidence  in  these  estimates  is  based  on 
the  rationale  for  the  selected  model  and  the  nature  of  the  data.  There 
may  be  occasions  where  the  available  historical  data  does  not  apply, 
such  as  where  efforts  are  unprecedented  or  where  the  type  of  task  does 
not  fit  available  models.  An  effort  is  unprecedented  (to  some  degree)  if 
a  similar  product  or  component  has  never  been  built.  An  effort  may  also 
be  unprecedented  if  the  development  group  has  never  built  such  a 
product  or  component,  [pai63.igioi.spio4.nioi] 
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Unprecedented  efforts  are  more  risky,  require  more  research  to  develop 
reasonable  bases  of  estimate,  and  require  more  management  reserve. 
The  uniqueness  of  the  project  must  be  documented  when  using  these 
models  to  ensure  a  common  understanding  of  any  assumptions  made 
in  the  initial  planning  stages,  [pai63.igioi.spio4.nio2] 


Typical  Work  Products 

1 .  Estimation  rationale  [pai63.igioi.spio4.wioi] 

2.  Project  effort  estimates  [pai63.igioi.spio4.wio2] 

3.  Project  cost  estimates  [pai63.igioi.spio4.wio4] 

Subpractices 

1 .  Collect  the  models  or  historical  data  that  will  be  used  to  transform 
the  attributes  of  the  work  products  and  tasks  into  estimates  of  the 
labor  hours  and  cost.  [PAi63.iGioi.spio4.subPioi] 

For  Software  Engineering 

Within  the  software-engineering  area,  many  parametric 
models  have  been  developed  to  aid  in  estimating  cost  and 
schedule.  The  use  of  these  models  as  the  sole  source  of 
estimation  is  not  recommended  as  these  models  are  based  on 
historical  project  data  that  may  or  may  not  be  pertinent  to  your 
project.  Multiple  models  and/or  methods  may  be  used  to 
ensure  a  high  level  of  confidence  in  the  estimate. 

[PA1 63.IG1 01  .SP1 04.SubP1 01  .AMP1 01] 

Historical  data  include  the  cost,  effort,  and  schedule  data  from  previously 
executed  projects,  plus  appropriate  scaling  data  to  account  for  differing  sizes  and 

complexity.  [PA163.IG101.SP104.SubP101.N101] 

2.  Include  supporting  infrastructure  needs  when  estimating  effort  and 

cost.  [PA1 63.IG1 01  SP1 04.SubP102] 

The  support  infrastructure  includes  items  needed  from  a  development  and 
sustainment  perspective  for  the  product.  [PAi63.iGio1.sp104.subPio2.Nioi] 

For  Software  Engineering 

Consider  critical  computer  resources  in  the  host  environment, 
in  the  test  environment,  in  the  target  environment,  or  in  any 
combination  of  these.  Computer  resource  estimation  typically 
includes  the  following:  [PAi63.tGioi.spio4.subPio2.Nioi.AMPioi] 

•  identifying  the  critical  computer  resources  for  the  software 
project  and 

•  basing  estimates  of  critical  computer  resources  on  allocated 
requirements 


198 


Project  Management,  Project  Planning 


CMMI-SW,  vl.1 
Continuous  Representation 

For  Software  Engineering 

Examples  of  critical  computer  resources  include  the  following: 

[PA163.IG1 01  .SP1 04.SubP102.N101  .AMP102] 

•  Memory,  disk,  and  network  capacity 

•  Processor  power 

•  Communications  channel  capacity 

•  Workstation  power 

•  Peripheral  capacity 

For  Software  Engineering 

Examples  of  software-engineering  facilities  include  the  following: 

[PA103.lG101.SP104.SubP102.N101.AMP103] 

•  Host  computers,  peripherals,  and  networks 

•  Software  test  computers  and  peripherals 

•  Target  computer  environment  software 

•  Software-engineering  environment  (i.e.,  software  toots) 

3.  Estimate  effort  and  cost  using  models  and/or  historical  data. 

[PA1 63.IG1 01  .SP1 04.SubP1 03] 

Effort  and  cost  inputs  used  for  estimating  typically  include  the  following: 

[PA163.IG101.SP104.SubP103.N101] 

•  Judgmental  estimates  provided  by  an  expert  or  group  of  experts  (e.g.,  Delphi 
Method) 

•  Risks,  including  the  extent  to  which  the  effort  is  unprecedented 

•  Critical  competencies  and  roles  needed  to  perform  the  work 

•  Product  and  product-component  requirements 

•  Technical  approach 

•  WBS 

•  Size  estimates  of  work  products  and  anticipated  changes 

•  Cost  of  externally  acquired  work  products 

•  Selected  project  life-cycle  model  and  processes 

•  Life-cycle  cost  estimates 

•  Capability  of  tools  provided  in  engineering  environment 

•  Skill  levels  of  managers  and  staff  needed  to  perform  the  work 

•  Knowledge,  skill,  and  training  needs 

•  Facilities  needed  (e.g.,  office  and  meeting  space  and  workstations) 

•  Engineering  facilities  needed 
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Capability  of  manufacturing  process(es) 
Travel 


•  Level  of  security  required  for  tasks,  work  products,  hardware,  software,  personnel, 
and  work  environment 

•  Service-level  agreements  for  call  centers  and  warranty  work 

•  Direct  labor  and  overhead 

SG  2  Develop  a  Project  Plan 


A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 

project.  [PA163.IG102] 

A  project  plan  is  a  formal,  approved  document  used  to  manage  and 
control  the  execution  of  the  project.  It  is  based  on  the  project 
requirements  and  the  established  estimates,  [pai63.igio2.nioi] 

The  project  plan  should  consider  all  phases  of  the  project  life  cycle. 
Project  planning  should  ensure  that  all  plans  affecting  the  project  are 
consistent  with  the  overall  project  plan,  [pai63.igio2.nio2] 


SP  2.1-1  Establish  the  Budget  and  Schedule 

Establish  and  maintain  the  project’s  budget  and  schedule. 

[PA163.IG102.SP101] 


The  project’s  budget  and  schedule  are  based  on  the  developed 
estimates  and  ensure  that  budget  allocation,  task  complexity,  and  task 
dependencies  are  appropriately  addressed,  [pai63.igio2.spioi.nioi] 

Event-driven,  resource-limited  schedules  have  proven  to  be  effective  in 
dealing  with  project  risk.  Identifying  accomplishments  to  be 
demonstrated  before  initiation  of  the  event  provides  some  flexibility  in 
the  timing  of  the  event,  a  common  understanding  of  what  is  expected,  a 
better  vision  of  the  state  of  the  project,  and  a  more  accurate  status  of 
the  project’s  tasks,  [pai63.igio2.spioi.nio2] 

Typical  Work  Products 

1.  Project  schedules  [pai63.igio2.spioi.wioi] 

2.  Schedule  dependencies  [pai63.igio2.spioi.wio2] 

3.  Project  budget  [pai63.igio2.spioi.wio3] 

Subpractices 

1.  Identify  major  milestones.  [PAi63.iGio2.spioi.subPioi] 
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Milestones  are  often  imposed  to  ensure  completion  of  certain  deliverables  by  the 
milestone.  Milestones  can  be  event  based  or  calendar  based.  If  calendar  based, 
once  milestone  dates  have  been  agreed  upon,  it  is  often  very  difficult  to  change 

them.  [PA163.IG102.SP101.SubP101.N101] 

2.  Identify  schedule  assumptions.  [PAi63.iGio2.spioi.subPio2] 

When  schedules  are  initially  developed,  it  is  common  to  make  assumptions  about 
the  duration  of  certain  activities.  These  assumptions  are  frequently  made  on  items 
for  which  little  if  any  estimation  data  is  available.  Identifying  these  assumptions 
provides  insight  into  the  level  of  confidence  (uncertainties)  in  the  overall  schedule. 

[PA163.IG102.SP101.SubP102.N101] 

3.  Identify  constraints.  [PAi63.iGio2.spioi.subPio3] 

Factors  that  limit  the  flexibility  of  management  options  need  to  be  identified  as 
early  as  possible.  The  examination  of  the  attributes  of  the  work  products  and 
tasks  will  often  surface  these  issues.  Such  attributes  can  include  task  duration, 
resources,  inputs,  and  outputs.  [PAi63.iGio2.sp101.subPio3.Nioi] 

4.  Identify  task  dependencies.  [PAi63.iGio2.spioi.subPio4] 

Typically,  the  tasks  fora  project  can  be  accomplished  in  some  ordered  sequence 
that  will  minimize  the  duration  of  the  project.  This  involves  the  identification  of 
predecessor  and  successor  tasks  to  determine  the  optimal  ordering. 

[PA163.IG102.SP101.SubP104.N101] 

Examples  of  tools  that  can  help  determine  an  optimal  ordering  of  task  activities 
include  the  following:  [PAi63.iGi02.sp101.subPi04.Ni02] 

•  Critical  Path  Method  (CPM) 

•  Program  Evaluation  and  Review  Technique  (PERT) 

•  Resource-limited  scheduling 

5.  Define  the  budget  and  schedule.  [PAi63.iGio2.spioi.subPios] 

Establishing  and  maintaining  the  project's  budget  and  schedule  typically  includes 
the  following:  [PAi63.iGi02.sp101.subPi05.Ni0i] 

•  Defining  the  committed  or  expected  availability  of  resources  and  facilities 

•  Determining  time  phasing  of  activities 

•  Determining  a  breakout  of  subordinate  schedules 

•  Defining  the  dependencies  between  the  activities  (predecessor  or  successor 
relationships) 

•  Defining  the  schedule  activities  and  milestones  to  support  accuracy  in  progress 
measurement 

•  Identifying  milestones  for  delivery  of  products  to  the  customer 

•  Defining  activities  of  appropriate  duration 
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•  Defining  milestones  of  appropriate  time  separation 

•  Defining  a  management  reserve  based  on  the  confidence  level  in  meeting  the 
schedule  and  budget 

•  Using  appropriate  historical  data  to  verify  the  schedule 

•  Defining  incremental  funding  requirements 

•  Documenting  project  assumptions  and  rationale 

6.  Establish  corrective  action  criteria.  [PAi63.iGio2.spioi.subPio6] 

Criteria  are  established  for  determining  what  constitutes  a  significant  deviation 
from  the  project  plan.  A  basis  for  gauging  issues  and  problems  is  necessary  to 
determine  when  a  corrective  action  should  be  taken.  The  corrective  actions  may 
require  re-planning,  which  may  include  revising  the  original  plan,  establishing  new 
agreements,  or  including  mitigation  activities  within  the  current  plan. 

[PA163.IG102.SP101.SubP106.N101] 


SP  2.2-1  Identify  Project  Risks 

Identify  and  analyze  project  risks.  [pai63.igio2.spio3] 


Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities,  ipaib3.igio2.spio3.rioi] 

Refer  to  the  Monitor  Project  Risks  specific  practice  in  the  Project 
Monitoring  and  Control  process  area  for  more  information  about  risk 
monitoring  activities,  [paib3.igio2.spio3.rio2] 

Risks  are  identified  or  discovered  and  analyzed  to  support  project 
planning.  This  specific  practice  should  be  extended  to  all  the  plans  that 
affect  the  project  to  ensure  that  the  appropriate  interfacing  is  taking 
place  between  all  relevant  stakeholders  on  identified  risks.  Project 
planning  risk  identification  and  analysis  typically  include  the  following: 

[PA163.IG102.SP103.N101] 

•  Identifying  risks 

•  Analyzing  the  risks  to  determine  the  impact,  probability  of 
occurrence,  and  time  frame  in  which  problems  are  likely  to  occur 

•  Prioritizing  risks 

Typical  Work  Products 

1 .  Identified  risks  [pai63.igio2.spio3.wioi] 

2.  Risk  impacts  and  probability  of  occurrence  [pai63.igio2.spio3.wio2] 

3.  Risk  priorities  [pai63.igio2.spio3.wio3] 

Subpractices 

1 .  Identify  risks.  [PAi63.iGio2.spio3.subPioi] 
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SP  2.3-1 


The  identification  of  risks  involves  the  identification  of  potential  issues,  hazards, 
threats,  vulnerabilities,  etc.  that  could  negatively  affect  work  efforts  and  plans. 
Risks  must  be  identified  and  described  in  an  understandable  way  before  they  can 
be  analyzed.  When  identifying  risks,  it  is  good  to  use  a  standard  method  for 
defining  risks.  Risk  identification  and  analysis  tools  may  be  used  to  help  identify 
possible  problems.  [PAi63.iGi02.sp103.subPi01.Ni0i] 

Examples  of  risk  identification  and  analysis  tools  include  the  following: 

[PA163.IG102.SP103.SubP101.N102] 

•  Risk  taxonomies 

•  Risk  assessments 

•  Checklists 

•  Structured  interviews 

•  Brainstorming 

•  Performance  models 

•  Cost  models 

•  Network  analysis 

•  Quality  factor  analysis 

2.  Document  the  risks.  [PAi63.iGio2.spio3.subPio2] 

3.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
completeness  and  correctness  of  the  documented  risks. 

[PA163.IG102.SP103.SubP103] 

4.  Revise  the  risks  as  appropriate.  [PAi63.iGio2.spio3.subPio4] 

Examples  of  when  identified  risks  may  need  to  be  revised  include  the  following: 

[PA163.IG102.SP103.SubP104.N101] 

•  When  new  risk  is  identified 

•  When  risks  become  problems 

•  When  risks  are  retired 

•  When  project  circumstances  change  significantly 


Plan  for  Data  Management 

Plan  for  the  management  of  project  data,  [pai63.igw2.spw2] 
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Data  are  the  various  forms  of  documentation  required  to  support  a 
program  in  all  of  its  areas  (e.g.,  administration,  engineering, 
configuration  management,  financial,  logistics,  quality,  safety, 
manufacturing,  and  procurement).  The  data  may  take  any  form  (e.g., 
reports,  manuals,  notebooks,  charts,  drawings,  specifications,  files,  or 
correspondence).  The  data  may  exist  in  any  medium  (e.g.,  printed  or 
drawn  on  various  materials,  photographs,  electronic,  or  multimedia). 
Data  may  be  deliverable  (e.g.,  items  identified  by  a  program’s  contract 
data  requirements)  or  data  may  be  nondeliverable  (e.g.,  informal  data, 
trade  studies  and  analyses,  internal  meeting  minutes,  internal  design 
review  documentation,  lessons  learned,  and  action  items).  Distribution 
may  take  many  forms,  including  electronic  transmission. 

[PA163.IG102.SP102.N101] 


The  data  requirements  for  the  project  should  be  established  for  both  the 
data  items  to  be  created  and  their  content  and  form,  based  on  a 
common  or  standard  set  of  data  requirements.  Uniform  content  and 
format  requirements  for  data  items  facilitate  understanding  of  data 
content  and  help  with  consistent  management  of  the  data  resources. 

[PA163.IG102.SP102.N102] 


The  reason  for  collecting  each  document  should  be  clear.  This  task 
includes  the  analysis  and  verification  of  project  deliverables  and 
nondeliverables,  contract  and  noncontract  data  requirements,  and 
customer-supplied  data.  Often,  data  is  collected  with  no  clear 
understanding  of  how  it  will  be  used.  Data  is  costly  and  should  be 
collected  only  when  needed,  [pai63.igio2.spio2.nio3] 

Typical  Work  Products 

1 .  Data  management  plan  [pai63.igio2.spio2.wioi] 

2.  Master  list  of  managed  data  [pai63.igio2.spio2.wio2] 

3.  Data  content  and  format  description  [pai63.igio2.spio2.wio3] 

4.  Data  requirements  lists  for  acquirers  and  for  suppliers 

[PA163.IG102.SP102.W104] 

5.  Privacy  requirements  [pai63.igio2.spio2.wio5] 

6.  Security  requirements  [pai63.igio2.spio2.wio6] 

7.  Security  procedures  [pai63.igio2.spio2.wio7] 

8.  Mechanism  for  data  retrieval,  reproduction,  and  distribution 

[PA163.IG102.SP102.W108] 

9.  Schedule  for  collection  of  project  data  [PAi63.iGi02.sp102.w109] 

10.  Listing  of  project  data  to  be  collected  [pai63.igio2.spio2.who] 
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Subpractices 

1 .  Establish  requirements  and  procedures  to  ensure  privacy  and 
security  of  the  data.  [PAi63.iGio2.spio2.subPioi] 

Not  everyone  will  have  the  need  or  clearance  necessary  to  access  the  project 
data.  Procedures  must  be  established  to  identify  who  has  access  to  what  data  as 
well  as  when  they  have  access  to  the  data.  [PAi63.iGio2.sp102.subPio1.Nioi] 

2.  Establish  a  mechanism  to  archive  data  and  to  access  archived 

data.  [PA163.IG102.SP1 02. SubPI 02] 

Accessed  information  should  be  in  an  understandable  form  (e.g.,  electronic  or 
computer  output  from  a  database)  or  represented  as  originally  generated. 

[PA163.IG102.SP102.SubP102.N101] 

3.  Determine  the  project  data  to  be  identified,  collected,  and 

distributed.  [PA163.IG102.SP102.SubP103] 


SP  2.4-1  Plan  for  Project  Resources 

Plan  for  necessary  resources  to  perform  the  project.  [paib3.igio2.spio4] 


Defining  project  resources  (labor,  machinery/equipment,  materials,  and 
methods)  and  quantities  needed  to  perform  project  activities  builds  on 
the  initial  estimates  and  provides  additional  information  that  can  be 
applied  to  expand  the  WBS  used  to  manage  the  project. 

[PA163.IG102.SP104.N101] 


The  top-level  WBS  developed  earlier  as  an  estimation  mechanism  is 
typically  expanded  by  decomposing  these  top  levels  into  work  packages 
that  represent  singular  work  units  that  can  be  separately  assigned, 
performed,  and  tracked.  This  subdivision  is  done  to  distribute 
management  responsibility  and  provide  better  management  control. 
Each  work  package  or  work  product  in  the  WBS  should  be  assigned  a 
unique  identifier  (e.g.,  number)  to  permit  tracking.  A  WBS  may  be 
based  on  requirements,  activities,  work  products,  or  a  combination  of 
these  items.  A  dictionary  that  describes  the  work  for  each  work  package 
in  the  WBS  should  accompany  the  work  breakdown  structure. 

[PA163.IG102.SP104.N102] 

Typical  Work  Products 

1 .  WBS  work  packages  [pai63.igio2.spio4.wioi] 

2.  WBS  task  dictionary  [pai63.igio2.spio4.wio2] 

3.  Staffing  requirements  based  on  project  size  and  scope 

[PA163.IG102.SP104.W103] 

4.  Critical  facilities/equipment  list  [pai63.igio2.spio4.wio4] 
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5.  Process/workflow  definitions  and  diagrams  [pai63.igio2.spio4.wio5] 

6.  Program  administration  requirements  list  [pai63.igio2.spio4.wio6] 

Subpractices 

1.  Determine  process  requirements.  [PAi63.iGio2.spio4.subPioi] 

The  processes  used  to  manage  a  project  must  be  identified,  defined,  and 
coordinated  with  all  the  relevant  stakeholders  to  ensure  efficient  operations  during 
project  execution.  [PAi63.iGio2.sp104.subPio1.Nioi] 

2.  Determine  staffing  requirements.  [PAi63.iGio2.spio4.subPio2] 

The  staffing  of  a  project  depends  on  the  decomposition  of  the  project 
requirements  into  tasks,  roles,  and  responsibilities  for  accomplishing  the  project 
requirements  as  laid  out  within  the  work  packages  of  the  WBS. 

[PA163.IG102.SP104.SubP102.N101] 

Staffing  requirements  must  consider  the  knowledge  and  skills  required  for  each  of 
the  identified  positions,  as  defined  in  the  Plan  for  Needed  Knowledge  and  Skills 
specific  practice.  [PAi63.iGi02.sp104.subPi02.Ni02] 

3.  Determine  facilities,  equipment,  and  component  requirements. 

[PA163.IG102.SP104.SubP103] 


Most  projects  are  unique  in  some  sense  and  require  some  set  of  unique  assets  to 
accomplish  the  objectives  of  the  project.  The  determination  and  acquisition  of 
these  assets  in  a  timely  manner  are  crucial  to  project  success. 

[PA163.IG102.SP104.SubP103.N101] 


Lead-time  items  need  to  be  identified  early  to  determine  how  they  will  be 
addressed.  Even  when  the  required  assets  are  not  unique,  compiling  a  list  of  all  of 
the  facilities,  equipment,  and  parts  (e.g.,  number  of  computers  for  the  personnel 
working  on  the  project,  software  applications,  office  space,  etc.)  provides  insight 
into  aspects  of  the  scope  of  an  effort  that  are  often  overlooked. 

[PA163.IG102.SP104.SubP103.N102] 


SP  2.5-1  Plan  for  Needed  Knowledge  and  Skills 

Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

[PA  163.IG102.SP105] 


Refer  to  the  Organizational  Training  process  area  for  more  information 
about  knowledge  and  skills  information  to  be  incorporated  into  the 

project  plan.  [PA163.IG102.SP105.R101] 

Knowledge  delivery  to  projects  involves  both  training  of  project 
personnel  and  acquisition  of  knowledge  from  outside  sources. 

[PA163.IG102.SP105.N101] 
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Staffing  requirements  are  dependent  on  the  knowledge  and  skills 
available  to  support  the  execution  of  the  project,  [pai63.igio2.spio5.nio2] 

Typical  Work  Products 

1 .  Inventory  of  skill  needs  [pai63.igio2.spio5.wioi] 

2.  Staffing  and  new  hire  plans  [pai63.igio2.spio5.wio3] 

3.  Databases  (e.g.,  skills  and  training)  [pai63.igio2.spio5.wio4] 

Subpractices 

1 .  Identify  the  knowledge  and  skills  needed  to  perform  the  project. 

[PA163.IG102.SP1 05. SubPI  01] 

2.  Assess  the  knowledge  and  skills  available.  [PAi63.iGio2.spio5.subPio2] 

3.  Select  mechanisms  for  providing  needed  knowledge  and  skills. 

[PA163.IG102.SP105.SubP103] 

Example  mechanisms  include  the  following:  [PAi63.iGio2.sp105.subPio3.Nioi] 

•  In-house  training  (both  organizational  and  project) 

•  External  training 

•  Staffing  and  new  hires 

•  External  skill  acquisition 

The  choice  of  in-house  training  or  external  outsourcing  for  the  needed  knowledge 
and  skills  is  determined  by  the  availability  of  training  expertise,  the  project's 
schedule,  and  business  objectives.  [PAi63.iGio2.sp105.subPio3.Nio2] 

4.  Incorporate  selected  mechanisms  in  the  project  plan. 

[PA163.IG102.SP105.SubP104] 


SP  2.6-1  Plan  Stakeholder  Involvement 

Plan  the  involvement  of  identified  stakeholders.  ipai63.igio2.spio6] 


Stakeholders  are  identified  from  all  phases  of  the  project  life  cycle  by 
identifying  the  type  of  people  and  functions  needing  representation  in 
the  project  and  describing  their  relevance  and  the  degree  of  interaction 
for  specific  project  activities.  A  two-dimensional  matrix  with 
stakeholders  along  one  axis  and  project  activities  along  the  other  axis  is 
a  convenient  format  for  accomplishing  this  identification.  Relevance  of 
the  stakeholder  to  the  activity  in  a  particular  project  phase  and  the 
amount  of  interaction  expected  would  be  shown  at  the  intersection  of 
the  project  phase  activity  axis  and  the  stakeholder  axis. 

[PA163.IG102.SP106.N101] 
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For  the  inputs  of  stakeholders  to  be  useful,  careful  selection  of  relevant 
stakeholders  is  necessary.  For  each  major  activity,  identify  the 
stakeholders  that  are  affected  by  the  activity  and  those  who  have 
expertise  that  is  needed  to  conduct  the  activity.  This  list  of  relevant 
stakeholders  will  probably  change  as  the  project  moves  through  the 
phases  of  the  project  life  cycle.  It  is  important,  however,  to  ensure  that 
relevant  stakeholders  in  the  later  phases  of  the  life  cycle  have  early 
input  to  requirements  and  design  decisions  that  affect  them. 

[PA163.IG102.SP106.N102] 


Examples  of  the  type  of  material  that  should  be  included  in  a  plan  for  stakeholder 

interaction  include  the  following:  [pai63.igio2.spio6.nio3] 

•  List  of  all  relevant  stakeholders 

•  Rationale  for  stakeholder  involvement 

•  Roles  and  responsibilities  of  the  relevant  stakeholders  with  respect  to  the  project, 
by  project  life-cycle  phase 

•  Relationships  between  stakeholders 

•  Relative  importance  of  the  stakeholder  to  success  of  the  project,  by  project  life- 
cycle  phase 

•  Resources  (e.g.,  training,  materials,  time,  funding)  needed  to  ensure  stakeholder 
interaction 

•  Schedule  for  phasing  of  stakeholder  interaction 


Conduct  of  this  specific  practice  relies  on  shared  or  exchanged 
information  with  the  previous  Plan  for  Needed  Knowledge  and  Skills 
specific  practice,  [pai63.igio2.spio6.nio4] 

Typical  Work  Products 

1 .  Stakeholder  involvement  plan  [pai63.igio2.spio6.wioi] 


SP  2.7-1  Establish  the  Project  Plan 

Establish  and  maintain  the  overall  project  plan  content. 

[PA163.IG102.SP107] 

For  Software  Engineering 

For  software,  the  planning  document  is  often  referred  to  as 

one  of  the  following:  [pai63.igio2.spio7.ampio2] 

•  Software  development  plan 

•  Software  project  plan 

•  Software  plan 
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A  documented  plan  that  addresses  all  relevant  planning  items  is 
necessary  to  achieve  the  mutual  understanding,  commitment,  and 
performance  of  individuals,  groups,  and  organizations  that  must 
execute  or  support  the  plans.  The  plan  generated  for  the  project  defines 
all  aspects  of  the  effort,  tying  together  in  a  logical  manner:  project  life- 
cycle  considerations;  technical  and  management  tasks;  budgets  and 
schedules;  milestones;  data  management,  risk  identification,  resource 
and  skill  requirements;  and  stakeholder  identification  and  interaction. 
Infrastructure  descriptions  include  responsibility  and  authority 
relationships  for  project  staff,  management,  and  support  organizations. 

[PA163.IG102.SP107.N101] 

Typical  Work  Products 

1 .  Overall  project  plan  [pai63.igio2.spio7.wioi] 


SG  3  Obtain  Commitment  to  the  Plan 


Commitments  to  the  project  plan  are  established  and  maintained.  [pai63.igio3] 

To  be  effective,  plans  require  commitment  by  those  responsible  for 
implementing  and  supporting  the  plan,  [pai63.igio3.nioi] 


SP  3.1-1  Review  Plans  that  Affect  the  Project 

Review  all  plans  that  affect  the  project  to  understand  project 
commitments,  [pai63.igio3.spw3] 


Plans  developed  within  other  process  areas  will  typically  contain 
information  similar  to  that  called  for  in  the  overall  project  plan.  These 
plans  may  provide  additional  detailed  guidance  and  should  be 
compatible  with  and  support  the  overall  project  plan  to  indicate  who  has 
the  authority,  responsibility,  accountability,  and  control.  All  plans  that 
affect  the  project  should  be  reviewed  to  ensure  a  common 
understanding  of  the  scope,  objectives,  roles,  and  relationships  that  are 
required  for  the  project  to  be  successful.  Many  of  these  plans  are 
described  by  the  Plan  the  Process  generic  practice  in  each  of  the 
process  areas,  [pai63.igio3.spio3.nioi] 

Typical  Work  Products 

1 .  Record  of  the  reviews  of  plans  that  affect  the  project 

[PA163.IG103.SP103.W101] 


SP  3.2-1  Reconcile  Work  and  Resource  Levels 

Reconcile  the  project  plan  to  reflect  available  and  estimated 
resources.  [paib3.igio3.spioi] 
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To  obtain  commitment  from  relevant  stakeholders,  it  is  important  to 
reconcile  any  differences  between  the  estimates  and  the  available 
resources.  Reconciliation  is  typically  accomplished  by  lowering  or 
deferring  technical  performance  requirements,  negotiating  more 
resources,  finding  ways  to  increase  productivity,  outsourcing,  adjusting 
the  staff  skill  mix,  or  revising  all  plans  that  affect  the  project  or 

schedules.  [PA163.IG103.SP101.N101] 

Typical  Work  Products 

1.  Revised  methods  and  corresponding  estimating  parameters  (e.g., 
better  tools,  use  of  off-the-shelf  components)  [pai63.igio3.spioi.wioi] 

2.  Renegotiated  budgets  [pai63.igio3.spioi.wio2] 

3.  Revised  schedules  [pai63.igio3.spioi.wio3] 

4.  Revised  requirements  list  [pai63.igio3.spioi.wio4] 

5.  Renegotiated  stakeholder  agreements  [pai63.igio3.spioi.wio5] 


SP  3.3-1  Obtain  Plan  Commitment 

Obtain  commitment  from  relevant  stakeholders  responsible  for 
performing  and  supporting  plan  execution,  [pai63.igw3.spw2] 


Obtaining  commitment  involves  interaction  among  all  relevant 
stakeholders  both  internal  and  external  to  the  project.  The  individual  or 
group  making  a  commitment  should  have  confidence  that  the  work  can 
be  performed  within  cost,  schedule,  and  performance  constraints. 
Often,  a  provisional  commitment  is  adequate  to  allow  the  effort  to  begin 
and  to  permit  research  to  be  performed  to  increase  confidence  to  the 
appropriate  level  needed  to  obtain  a  full  commitment,  [pai63.igio3.spio2.nioi] 

Typical  Work  Products 

1 .  Documented  requests  for  commitments  [pai63.igio3.spio2.wioi] 

2.  Documented  commitments  [PAi63.iGi03.sp102.w102] 

Subpractices 

1.  Identify  needed  support  and  negotiate  commitments  with  relevant 
stakeholders.  [PAi63.iGio3.spio2.subPioi] 

The  WBS  can  be  used  as  a  checklist  for  ensuring  that  commitments  are  obtained 
for  all  tasks.  [PAi63.iGi03.sp102.subPi01.Ni0i] 

The  plan  for  stakeholder  interaction  should  identify  all  parties  from  whom 
commitment  should  be  obtained.  [PAi63.iGi03.sp102.subPi01.Ni02] 
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2.  Document  all  organizational  commitments,  both  full  and 
provisional,  ensuring  appropriate  level  of  signatories. 

[PA163.IG103.SP102.SubP102] 

Commitments  must  be  documented  to  ensure  a  consistent  mutual  understanding 
as  well  as  for  tracking  and  maintenance.  Provisional  commitments  should  be 
accompanied  by  a  description  of  the  risks  associated  with  the  relationship. 

[PA163.IG103.SP102.SubP102.N101] 

3.  Review  internal  commitments  with  senior  management  as 
appropriate.  [PAi63.iGio3.spio2.subPio3] 

4.  Review  external  commitments  with  senior  management  as 
appropriate.  [PAi63.iGio3.spio2.subPio4] 

Management  may  have  the  necessary  insight  and  authority  to  reduce  risks 
associated  with  external  commitments.  [PAi63.iGi03.sp102.subPi04.Ni0i] 

5.  Identify  commitments  on  interfaces  between  elements  in  the 
project,  and  with  other  projects  and  organizational  units,  so  they 
can  be  monitored.  [PAi63.iGio3.spio2.subPio5] 

Well-defined  interface  specifications  form  the  basis  for  commitments. 

[PA163.IG103.SP102.SubP105.N101] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  project  planning  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area.  [GP1021 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  project  planning  process.  [gpio3] 
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Elaboration: 

This  policy  establishes  organizational  expectations  for  estimating  the 
planning  parameters,  making  internal  and  external  commitments,  and 
developing  the  plan  for  managing  the  project.  [pai63.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  project 
planning  process.  [gpio4] 


Elaboration: 

This  plan  for  performing  the  project  planning  process  differs  from  the 
project  plan  described  in  specific  practices  in  this  process  area.  The 
plan  called  for  in  this  generic  practice  would  address  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process 
area,  from  estimating  the  scope  of  the  project  all  the  way  to  obtaining 
commitment  for  the  project  plan.  In  other  words,  this  generic  practice 
calls  for  one  to  “plan  the  plan.”  In  contrast,  the  project  plan  called  for  in 
the  specific  practices  would  address  planning  for  the  project  effort  itself 
in  a  comprehensive  manner.  [pai63.elio3] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  project  planning 
process,  developing  the  work  products,  and  providing  the  services 
of  the  process,  [gpios] 

Elaboration: 

Special  expertise,  equipment,  and  facilities  in  project  planning  may  be 
required.  Special  expertise  in  project  planning  may  include  the 
following:  [pai63.elio4] 

•  Experienced  estimators 

•  Schedulers 

•  Technical  experts  in  applicable  areas  (e.g.,  product  domain  and 
technology) 

Examples  of  other  resources  provided  include  the  following  tools:  [pai63.eho6] 

•  Spreadsheet  programs 

•  Estimating  models 

•  Project  planning  and  scheduling  packages 


212 


Project  Management,  Project  Planning 


CMMI-SW,  vl.1 
Continuous  Representation 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
project  planning  process,  [gpiobj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  project  planning 
process  as  needed,  [g pio7] 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pai63.elios] 

•  Estimating 

•  Budgeting 

•  Negotiating 

•  Risk  identification  and  analysis 

•  Data  management 

•  Planning 

•  Scheduling 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  project  planning  process 
under  appropriate  levels  of  configuration  management,  igpioq] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai63.elhoi 

•  Work  breakdown  structure 

•  Project  plan 

•  Data  management  plan 

•  Stakeholder  involvement  plan 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  project 
planning  process  as  planned.  [gpu4} 
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Elaboration: 

This  generic  practice  is  different  from  developing  the  plan  for 
stakeholder  involvement  for  the  project  itself,  which  is  covered  in  a 
specific  practice  of  this  process  area.  [pai63.elihj 

Select  relevant  stakeholders  from  senior  managers,  project  managers, 
project  functional  managers  (e.g.,  systems  engineering,  software 
engineering,  other  disciplines),  software  engineers,  systems  engineers, 
manufacturing  engineers,  logisticians,  suppliers,  customers,  and  others 
who  may  be  affected  by,  or  may  affect,  the  project.  [pai63.elhs] 


Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai63.elh9] 

•  Establishing  estimates 

•  Reviewing  and  resolving  issues  on  the  completeness  and  correctness  of  the 
project  risks 

•  Reviewing  data  management  plans 

•  Establishing  project  plans 

•  Reviewing  project  plans  and  resolving  issues  on  work  and  resource  issues 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  project  planning  process  against  the  plan 
for  performing  the  process  and  take  appropriate  corrective  action. 

[GP110] 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA1 63.EL1 1 3] 

•  Number  of  revisions  to  the  plan 

•  Cost,  schedule,  and  effort  variance  per  plan  revision 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  project  planning  process 
against  its  process  description,  standards,  and  procedures,  and 
address  noncompliance,  [gpu3] 
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Examples  of  activities  reviewed  include  the  following:  [pai63.elh5] 

•  Establishing  estimates 

•  Developing  a  project  plan 

•  Obtaining  commitments  to  the  project  plan 

Examples  of  work  products  reviewed  include  the  following:  [pai63.elh7] 

•  WBS 

•  Project  plan 

•  Data  management  plan 

•  Stakeholder  involvement  plan 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  project  planning 
process  with  higher  level  management  and  resolve  issues.  igph2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  project 
planning  process,  [g piuj 

Collect  Improvement  Information 

GG  4  Institution 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  project  planning  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[GP117] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  project 
planning  process  that  address  quality  and  process  performance 
based  on  customer  needs  and  business  objectives,  [gpusj 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  project  planning  process  to  achieve  the 
established  quantitative  quality  and  process-performance 
objectives,  [gpiw] 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  project  planning  process 
in  fulfilling  the  relevant  business  objectives  of  the  organization. 

[GP12S] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  project  planning  process.  igpi2ij 
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PROJECT  MONITORING  AND  CONTROL 

Project  Management 


Purpose 


The  purpose  of  Project  Monitoring  and  Control  is  to  provide  an 
understanding  of  the  project’s  progress  so  that  appropriate  corrective 
actions  can  be  taken  when  the  project’s  performance  deviates 
significantly  from  the  plan,  [pai 62] 


Introductory  Notes 


A  project's  documented  plan  is  the  basis  for  monitoring  activities, 
communicating  status,  and  taking  corrective  action.  Progress  is 
primarily  determined  by  comparing  actual  work  product  and  task 
attributes,  effort,  cost,  and  schedule  to  the  plan  at  prescribed 
milestones  or  control  levels  within  the  project  schedule  or  work 
breakdown  structure.  Appropriate  visibility  enables  timely  corrective 
action  to  be  taken  when  performance  deviates  significantly  from  the 
plan.  A  deviation  is  significant  if,  when  left  unresolved,  it  precludes  the 
project  from  meeting  its  objectives.  [pai62.nioij 

The  term  “project  plan”  is  used  throughout  these  practices  to  refer  to  the 
overall  plan  for  controlling  the  project.  [PAI62.N102] 

When  actual  status  deviates  significantly  from  the  expected  values, 
corrective  actions  are  taken  as  appropriate.  These  actions  may  require 
re-planning,  which  may  include  revising  the  original  plan,  establishing 
new  agreements,  or  including  additional  mitigation  activities  within  the 
current  plan.  [pai62.nio3] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
the  project  plan,  including  how  it  specifies  the  appropriate  level  of 
project  monitoring,  the  measures  used  to  monitor  progress,  and  known 
risks.  [pai62.rioi] 

Refer  to  the  Measurement  and  Analysis  process  area  for  information 
about  the  process  of  measuring,  analyzing,  and  recording  information. 

[PA162.R102] 
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Specific  Goals 


SG  1  Monitor  Project  Against  Plan  [pai62.igioi] 

Actual  performance  and  progress  of  the  project  are  monitored  against  the 
project  plan. 


SG  2  Manage  Corrective  Action  to  Closure  [pai62 .10102] 

Corrective  actions  are  managed  to  closure  when  the  project's  performance  or 
results  deviate  significantly  from  the  plan. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkh.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Monitor  Project  Against  Plan  [pai62.igioi] 

SP  1.1-1  Monitor  Project  Planning  Parameters 

SP  1.2-1  Monitor  Commitments 

SP  1 .3-1  Monitor  Project  Risks 

SP  1.4-1  Monitor  Data  Management 

SP  1 .5-1  Monitor  Stakeholder  Involvement 

SP  1.6-1  Conduct  Progress  Reviews 
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SP  1.7-1 

Conduct  Milestone  Reviews 

SG  2  Manage  Corrective  Action  to  Closure  [pai62.igio2] 

SP  2.1-1 

Analyze  Issues 

SP  2.2-1 

Take  Corrective  Action 

SP  2.3-1 

Manage  Corrective  Action 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [cl«>3.glioi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clim.glioii 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Monitor  Project  Against  Plan 


Actual  performance  and  progress  of  the  project  are  monitored  against  the 
project  plan.  [pai62.igioii 


SP  1.1-1  Monitor  Project  Planning  Parameters 

Monitor  the  actual  values  of  the  project  planning  parameters 
against  the  project  plan,  [pm62.igioi.spwi] 


Project  planning  parameters  constitute  typical  indicators  of  project 
progress  and  performance  and  include  attributes  of  work  products  and 
tasks,  cost,  effort,  and  schedule.  Attributes  of  the  work  products  and 
tasks  include  such  items  as  size,  complexity,  weight,  form,  fit,  or 

function.  [PA162.IG101.SP101.N101] 
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Monitoring  typically  involves  measuring  the  actual  values  of  project 
planning  parameters,  comparing  actual  values  to  the  estimates  in  the 
plan,  and  identifying  significant  deviations.  Recording  actual  values  of 
the  project  planning  parameters  includes  recording  associated 
contextual  information  to  help  understand  the  measures.  An  analysis  of 
the  impact  that  significant  deviations  have  on  determining  what 
corrective  actions  to  take  is  handled  in  the  second  specific  goal  and  its 
specific  practices  in  this  process  area,  [pai62.igioi.spioi.nio2] 

Typical  Work  Products 

1 .  Records  of  project  performance  [pai62.igioi.spioi.wioi] 

2.  Records  of  significant  deviations  [pai62.igioi.spioi.wio2] 

Subpractices 

1 .  Monitor  progress  against  the  schedule.  [PAi62.iGioi.spioi.subPioi] 

Progress  monitoring  typically  includes  the  following:  [PAi62.iGioi.spioi.subPioi.Nioi] 

•  Periodically  measuring  the  actual  completion  of  activities  and  milestones 

•  Comparing  actual  completion  of  activities  and  milestones  against  the  schedule 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  schedule  estimates  in  the  project  plan 

2.  Monitor  the  project's  cost  and  expended  effort.  [PAi62.iGioi.spioi.subPio2] 

Effort  and  cost  monitoring  typically  includes  the  following:  [PAi62.iGi01.sp101.subPi02.Ni0i] 

•  Periodically  measuring  the  actual  effort  and  cost  expended  and  staff  assigned 

•  Comparing  actual  effort,  costs,  staffing,  and  training  to  the  estimates  and  budgets 
documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  budgets  in  the  project  plan 

3.  Monitor  the  attributes  of  the  work  products  and  tasks. 

[PA162.IG101.SP101.SubP103] 

Refer  to  the  Project  Planning  process  area  for  information  about 
the  attributes  of  work  products  and  tasks.  [PAie2.iGi01.sp101.subPi03.Ri0i] 

Monitoring  the  attributes  of  the  work  products  and  tasks  typically  includes  the 
following:  [PAi62.iGio1.sp101.subPio3.Nioi] 

•  Periodically  measuring  the  actual  attributes  of  the  work  products  and  tasks,  such 
as  size  or  complexity  (and  the  changes  to  the  attributes) 

•  Comparing  the  actual  attributes  of  the  work  products  and  tasks  (and  the  changes 
to  the  attributes)  to  the  estimates  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  estimates  in  the  project  plan 

4.  Monitor  resources  provided  and  used.  [PAi62.iGioi.spioi.subPio4] 
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Refer  to  the  Project  Planning  process  area  for  information  about 
planned  resources.  [PAi62.iGi01.sp101.subPi04.Ri0i] 

For  Software  Engineering 

Examples  of  software-engineering  resources  include  the  following: 

[PA162.IG101.SP101.SubP104.AMP101] 

•  Host  computers  and  peripherals 

•  Networks 

•  Software  test  computers  and  peripherals 

•  Target  computer  environment  software 

•  Software-engineering  environment  (e.g.,  software  toots) 

Examples  of  resources  include:  [PAi62.iGio1.sp101.subPio4.Nioi] 

•  Physical  facilities 

•  Computers,  peripherals,  and  software  used  in  design,  manufacturing,  testing  and 
operation 

•  Networks 

•  Security  environment 

•  Project  staff 

•  Processes 

5.  Monitor  the  knowledge  and  skills  of  project  personnel. 

[PA162.IG101.SP101.SubP105] 

Refer  to  the  Project  Planning  process  area  for  information  about 
planning  for  knowledge  and  skills  needed  to  perform  the  project. 

[PA162.IG101.SP101.SubP105.R101] 

Monitoring  the  knowledge  and  skills  of  the  project  personnel  typically  includes  the 
following:  [PAi62.iGio1.sp101.subPio5.Nioi] 

•  Periodically  measuring  the  acquisition  of  knowledge  and  skills  by  project 
personnel 

•  Comparing  the  actual  training  obtained  to  that  documented  in  the  project  plan 

•  Identifying  significant  deviations  from  the  estimates  in  the  project  plan 

6.  Document  the  significant  deviations  in  the  project  planning 
parameters.  [PAi62.iGioi.spioi.subPio6] 


SP  1.2-1  Monitor  Commitments 

Monitor  commitments  against  those  identified  in  the  project  plan. 

[PA162.IG101.SP102] 
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Typical  Work  Products 

1 .  Records  of  commitment  reviews  [pai62.igioi.spio2.wioi] 

Subpractices 

1 .  Regularly  review  commitments  (both  external  and  internal). 

[PA162.IG101.SP102.SubP101] 

2.  Identify  commitments  that  have  not  been  satisfied  or  which  are  at 
significant  risk  of  not  being  satisfied.  [PAi62.iGioi.spio2.subPio2] 

3.  Document  the  results  of  the  commitment  reviews. 

[PA162.IG101.SP102.SubP103] 

SP  1.3-1  Monitor  Project  Risks 

Monitor  risks  against  those  identified  in  the  project  plan. 

[PA1 62.IG1 01  .SP1 03] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  project  risks,  i pm62.igioi.spw3.rioi j 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
risk  management  activities,  [pm62.igioi.spw3.rio2] 

Typical  Work  Products 

1 .  Records  of  project  risk  monitoring  [pai62.igioi.spio3.wioi] 

Subpractices 

1 .  Periodically  review  the  documentation  of  the  risks  in  the  context  of 
the  project’s  current  status  and  circumstances.  [PAi62.iGioi.spio3.subPioi] 

2.  Revise  the  documentation  of  the  risks,  as  additional  information 
becomes  available,  to  incorporate  changes.  [PAi62.iGioi.spio3.subPio2] 

3.  Communicate  risk  status  to  relevant  stakeholders. 

[PA162.IG101.SP103.SubP103] 

Examples  of  risk  status  include  the  following:  [PAi62.iGi01.sp103.subPi03.Ni0i] 

•  A  change  in  the  probability  that  the  risk  occurs 

•  A  change  in  risk  priority 


SP  1.4-1  Monitor  Data  Management 

Monitor  the  management  of  project  data  against  the  project  plan. 

[PA162.IG101.SP106] 
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Refer  to  the  Plan  for  Data  Management  specific  practice  in  the  Project 
Planning  process  area  for  more  information  about  identifying  the  types 
of  data  that  should  be  managed  and  how  to  plan  for  their  management. 

[PA1B2.IG101.SP106.R101] 

Once  the  plans  for  the  management  of  project  data  are  made,  the 
management  of  that  data  must  be  monitored  to  ensure  that  those  plans 
are  accomplished,  [pai62.igioi.spio6.nioi] 

Typical  Work  Products 

1 .  Records  of  data  management  [pai62.igioi.spio6.wioi] 

Subpractices 

1 .  Periodically  review  data  management  activities  against  their 
description  in  the  project  plan.  [PAi62.iGioi.spioe.subPioi] 

2.  Identify  and  document  significant  issues  and  their  impacts. 

[PA1 62.IG1 01  .SP1 06.SubP1 02] 

3.  Document  the  results  of  data  management  activity  reviews. 

[PA162.IG101.SP106.SubP103] 


SP  1.5-1  Monitor  Stakeholder  Involvement 

Monitor  stakeholder  involvement  against  the  project  plan. 

[PA162.IG101.SP1 07] 

Refer  to  the  Plan  Stakeholder  Involvement  specific  practice  in  the 
Project  Planning  process  area  for  more  information  on  identifying 
relevant  stakeholders  and  planning  the  appropriate  involvement  with 

them.  [PA162.IG101.SP107.R101] 

Once  the  stakeholders  are  identified  and  the  extent  of  their  involvement 
within  the  project  is  specified  in  project  planning,  that  involvement  must 
be  monitored  to  ensure  that  the  appropriate  interactions  are  occurring. 

[PA162.IG101.SP107.N101] 

Typical  Work  Products 

1 .  Records  of  stakeholder  involvement  [pai62.igioi.spio7.wioi] 

Subpractices 

1 .  Periodically  review  the  status  of  stakeholder  involvement. 

[PA162.IG101.SP107.SubP101] 

2.  Identify  and  document  significant  issues  and  their  impacts. 

[PA162.IG101.SP107.SubP102] 

3.  Document  the  results  of  the  stakeholder  involvement  status 

reviews.  [PA162.IG101.SP107.SubP103] 
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SP  1.6-1  Conduct  Progress  Reviews 

Periodically  review  the  project's  progress,  performance,  and 

issues.  [PA162.IG101.SP104] 

Progress  reviews  are  reviews  on  the  project  to  keep  stakeholders 
informed.  These  project  reviews  can  be  informal  reviews  and  may  not 
be  specified  explicitly  in  the  project  plans,  [pai62.igioi.spio4.nioi] 

Examples  of  these  reviews  include  the  following:  [pai62.igioi.spio4.nio2] 

•  Reviews  with  staff 

•  Reviews  with  project  engineers  and  support 

•  Reviews  with  management 


Typical  Work  Products 

1.  Documented  project  review  results  [pai62.igioi.spio4.wioi] 

Subpractices 

1 .  Regularly  communicate  status  on  assigned  activities  and  work 
products  to  relevant  stakeholders.  [PAi62.iGioi.spio4.subPioi] 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  reviews  as  appropriate. 

[PA162.IG101.SP104.SubP101.N101] 

2.  Review  the  results  of  collecting  and  analyzing  measures  for 
controlling  the  project.  [PAi62.iGioi.spio4.subPio2] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  process  for  measuring  and  analyzing  project 
performance  data.  [PAie2.iGi01.sp104.subPi02.Ri0i] 

3.  Identify  and  document  significant  issues  and  deviations  from  the 

plan.  [PA162.IG101  .SP104.SubP103] 

4.  Document  change  requests  and  problems  identified  in  any  of  the 
work  products  and  processes.  [PAi62.iGioi.spio4.subPio4] 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  how  changes  are  managed. 

[PA162.IG101.SP104.SubP104.R101] 

5.  Document  the  results  of  the  reviews.  [PAi62.iGioi.spio4.subPio5] 

6.  Track  change  requests  and  problem  reports  to  closure. 

[PA162.IG101.SP104.SubP106] 
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SP  1.7-1  Conduct  Milestone  Reviews 

Review  the  accomplishments  and  results  of  the  project  at  selected 
project  milestones,  [pai62.igioi.spw5] 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
milestone  planning,  [pai62.igioi.spios.rwi] 

Milestone  reviews  are  planned  during  project  planning  and  are  typically 
formal  reviews,  [pai62.igioi.spio5.nioi] 

Typical  Work  Products 

1.  Documented  milestone  review  results  [pai62.igioi.spio5.wioi] 

Subpractices 

1 .  Conduct  reviews  at  meaningful  points  in  the  project's  schedule, 
such  as  the  completion  of  selected  stages,  with  relevant 
stakeholders.  [PAi62.iGioi.spio5.subPioi] 

Managers,  staff  members,  customers,  end  users,  suppliers,  and  other  relevant 
stakeholders  within  the  organization  are  included  in  the  milestone  reviews  as 
appropriate.  [PAi62.iGi01.sp105.subPi01.Ni0i] 

2.  Review  the  commitments,  plan,  status,  and  risks  of  the  project. 

[PA162.IG101.SP105.SubP102] 

3.  Identify  and  document  significant  issues  and  their  impacts. 

[PA162.IG101.SP105.SubP103] 

4.  Document  the  results  of  the  review,  action  items,  and  decisions. 

[PA1 62.IG1 01  .SP1 05.SubP1 04] 

5.  Track  action  items  to  closure.  [PAi62.iGioi.spio5.subPios] 


SG  2  Manage  Corrective  Action  to  Closure 


Corrective  actions  are  managed  to  closure  when  the  project's  performance  or 
results  deviate  significantly  from  the  plan.  [paw2.igw2] 


SP  2.1-1  Analyze  Issues 

Collect  and  analyze  the  issues  and  determine  the  corrective 
actions  necessary  to  address  the  issues,  [pai62.igw2.spwi] 

Typical  Work  Products 

1 .  List  of  issues  needing  corrective  actions  [pai62.igio2.spioi.wioi] 

Subpractices 

1 .  Gather  issues  for  analysis.  [PAi62.iGio2.spioi.subPioi] 
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Issues  are  collected  from  reviews  and  the  execution  of  other  processes. 

[PA162.IG102.SP101.SubP101.N101] 

Examples  of  issues  to  be  gathered  include:  [PAi62.iGi02.sp101.subPi01.Ni02] 

•  Issues  discovered  through  performing  verification  and  validation  activities 

•  Significant  deviations  in  the  project  planning  parameters  from  the  estimates  in  the 
project  plan 

•  Commitments  (either  internal  or  external)  that  have  not  been  satisfied 

•  Significant  changes  in  risk  status 

•  Data  access,  collection,  privacy,  or  security  issues 

•  Stakeholder  representation  or  involvement  issues 

2.  Analyze  issues  to  determine  need  for  corrective  action. 

[PA162.IG102.SP101.SubP102] 

Refer  to  the  Project  Planning  process  area  for  information  about 
corrective  action  criteria.  [PAi62.iGi02.sp101.subPi02.Ri0i] 

Corrective  action  is  required  when  the  issue,  if  left  unresolved,  may  prevent  the 
project  from  meeting  its  objectives.  [PAi62.iGio2.sp101.subPio2.Nioi] 


SP  2.2-1  Take  Corrective  Action 

Take  corrective  action  on  identified  issues.  [PAi62.iGi02.spw2] 


Typical  Work  Products 

1 .  Corrective  action  plan  [PAi62.iGi02.sp102.w10i] 

Subpractices 

1 .  Determine  and  document  the  appropriate  actions  needed  to 
address  the  identified  issues.  [PAi62.iGio2.spio2.subPioi] 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  the  project  plan  when  re-planning  is  needed. 

[PA162.IG102.SP102.SubP101.R101] 
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Examples  of  potential  actions  include  the  following:  [PAi62.iGio2.sp102.subPio1.Nioi] 

•  Modifying  the  statement  of  work 

•  Modifying  requirements 

•  Revising  estimates  and  plans 

•  Renegotiating  commitments 

•  Adding  resources 

•  Changing  processes 

•  Revising  project  risks 

2.  Review  and  get  agreement  with  relevant  stakeholders  on  the 
actions  to  be  taken.  [PAi62.iGio2.spio2.subPio2] 

3.  Negotiate  changes  to  internal  and  external  commitments. 

[PA162.IG102.SP102.SubP103] 


SP  2.3-1  Manage  Corrective  Action 

Manage  corrective  actions  to  closure,  [pmb2.igio2.spi 03] 

Typical  Work  Products 

1 .  Corrective  action  results  [PAie2.iGi02.sp103.w10i] 

Subpractices 

1 .  Monitor  corrective  actions  for  completion.  [PAi62.iGio2.spio3.subPioi] 

2.  Analyze  results  of  corrective  actions  to  determine  the  effectiveness 
of  the  corrective  actions.  [PAi62.iGio2.spio3.subPio2] 

3.  Determine  and  document  appropriate  actions  to  correct  deviations 
from  planned  results  for  corrective  actions.  [PAi62.iGio2.spio3.subPio3] 

Lessons  learned  as  a  result  of  taking  corrective  action  can  be  inputs  to  planning 
and  risk  management  processes.  [PAi62.iGio2.sp103.subPio3.Nioi] 

Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 
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GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  project  monitoring  and  control 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  igpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  project  monitoring  and  control  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  monitoring 
performance  against  the  project  plan  and  managing  corrective  action  to 
closure  when  actual  performance  or  results  deviate  significantly  from 
the  plan.  [pai62.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  project 
monitoring  and  control  process.  [gpio4] 


Elaboration: 

This  plan  for  performing  the  project  monitoring  and  control  process  is 
typically  a  part  of  the  project  plan,  as  described  in  the  Project  Planning 
process  area.  [pai62.elio2] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  project  monitoring 
and  control  process,  developing  the  work  products,  and  providing 
the  services  of  the  process,  [gpiosj 
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Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pais2.elio3] 

•  Cost  tracking  systems 

•  Effort  reporting  systems 

•  Action-item-tracking  systems 

•  Project  management  and  scheduling  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
project  monitoring  and  control  process,  igpwbi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  project  monitoring 
and  control  process  as  needed,  [g pio7] 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pai62.elio4] 

•  Monitoring  and  control  of  projects 

•  Risk  management 

•  Data  management 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  project  monitoring  and 
control  process  under  appropriate  levels  of  configuration 
management,  [g piosj 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  project 
monitoring  and  control  process  as  planned.  [GPm 


Elaboration: 

This  generic  practice  is  different  from  monitoring  stakeholder  interaction 
for  the  project,  which  is  covered  by  a  specific  practice  in  this  process 
area.  [pai62.elio7] 
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Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai62.elios] 

•  Assessing  the  project  against  the  plan 

•  Reviewing  commitments  and  resolving  issues 

•  Reviewing  project  risks 

•  Reviewing  data  management  activities 

•  Reviewing  project  progress 

•  Managing  corrective  actions  to  closure 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  project  monitoring  and  control  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuo] 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA162.EL105] 

•  Number  of  open  and  closed  corrective  actions 

•  Project  milestone  dates  (e.g.,  planned  versus  actual  and  slipped  milestones) 

•  Number  and  types  of  reviews  performed 

•  Review  schedule  (planned  versus  actual  and  slipped  target  dates) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  project  monitoring  and 
control  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [gphsj 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai62.elio6] 

•  Monitoring  project  performance  against  the  project  plan 

•  Managing  corrective  actions  to  closure 

Examples  of  work  products  reviewed  include  the  following:  [pai62.elio9] 

•  Records  of  project  performance 

•  Project  review  results 
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GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institution; 

Review  the  activities,  status,  and  results  of  the  project  monitoring 
and  control  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 

alize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  project 
monitoring  and  control  process,  igpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  project  monitoring  and  control  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the  project 
monitoring  and  control  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP118] 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  project  monitoring  and  control  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  igpus] 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 
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GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  project  monitoring  and 
control  process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [gpi2si 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  project  monitoring  and  control  process.  [GP121} 
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SUPPLIER  AGREEMENT  MANAGEMENT 

Project  Management 


Purpose 


The  purpose  of  Supplier  Agreement  Management  is  to  manage  the 
acquisition  of  products  from  suppliers  for  which  there  exists  a  formal 
agreement.  [PAieej 


Introductory  Notes 


The  Supplier  Agreement  Management  process  area  involves  the 
following:  [pai66.nio4] 

•  Determining  the  type  of  acquisition  that  will  be  used  for  the 
products  to  be  acquired 

•  Selecting  suppliers 

•  Establishing  and  maintaining  agreements  with  suppliers 

•  Executing  the  supplier  agreement 

•  Accepting  delivery  of  acquired  products 

•  Transitioning  acquired  products  to  the  project 

This  process  area  primarily  applies  to  the  acquisition  of  products  and 
product  components  that  are  delivered  to  the  project’s  customer.  To 
minimize  risks  to  the  project,  this  process  area  may  also  be  applied  to 
the  acquisition  of  significant  products  and  product  components  not 
delivered  to  the  project’s  customer  (for  example,  development  tools  and 
test  environments).  [PAiee.Nios] 


This  process  area  does  not  directly  address  arrangements  in  which  the 
supplier  is  integrated  into  the  project  team  (for  example,  integrated 
product  teams).  Typically,  these  situations  are  handled  by  other 
processes  or  functions,  possibly  external  to  the  project,  though  some  of 
the  specific  practices  of  this  process  area  may  be  useful  in  managing 
the  formal  agreement  with  such  a  supplier.  [PAiee.Nioe] 

Suppliers  may  take  many  forms  depending  on  business  needs, 
including  in-house  vendors  (i.e.,  vendors  that  are  in  the  same 
organization  but  are  external  to  the  project),  fabrication  capabilities  and 
laboratories,  and  commercial  vendors.  [pai66.nio3] 

See  the  definition  of  “supplier”  in  Appendix  C,  the  glossary.  [pai66.nio7] 
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A  formal  agreement  is  any  legal  agreement  between  the  organization 
(representing  the  project)  and  the  supplier.  This  agreement  may  be  a 
contract,  a  license,  or  a  memorandum  of  agreement.  The  acquired 
product  is  delivered  to  the  project  from  the  supplier  and  becomes  part  of 
the  products  delivered  to  the  customer.  [pai66.nioii 

See  Chapter  3  for  an  explanation  of  how  “product”  is  used  in  the  CMMI 
Product  Suite.  [PAiee.Nios] 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  projects  and  taking  corrective  action. 

[PA166.R101] 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  defining  requirements.  [PAI66.R1021 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements,  including  the  traceability  of 
requirements  for  products  acquired  from  suppliers.  [pai66.rio3] 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
determining  the  products  and  product  components  that  may  be 
acquired  from  suppliers.  [pai66.rio4] 


Specific  Goals 

SG  1  Establish  Supplier  Agreements  [pai66.igioii 

Agreements  with  the  suppliers  are  established  and  maintained. 

SG  2  Satisfy  Supplier  Agreements  [paisb .101021 

Agreements  with  the  suppliers  are  satisfied  by  both  the  project  and  the 
supplier. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 
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GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clw.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosguoi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Establish  Supplier  Agreements  [paigs.igioi] 

SP  1.1-1  Determine  Acquisition  Type 

SP  1.2-1  Select  Suppliers 

SP  1.3-1  Establish  Supplier  Agreements 

SG  2  Satisfy  Supplier  Agreements  [pai66.igio2] 

SP  2.1-1  Review  COTS  Products 

SP  2.2-1  Execute  the  Supplier  Agreement 

SP  2.3-1  Accept  the  Acquired  Product 

SP  2.4-1  Transition  Products 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clio4.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 
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GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliobglioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Establish  Supplier  Agreements 


Agreements  with  the  suppliers  are  established  and  maintained,  [pawb.igioi] 


SP  1.1-1  Determine  Acquisition  Type 

Determine  the  type  of  acquisition  for  each  product  or  product 
component  to  be  acquired,  [pai66.igwi.spwi] 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
identifying  the  products  and  product  components  to  be  acquired. 

[PA166.IG101.SP101.R101] 


There  are  many  different  types  of  acquisition  that  can  be  used  to 
acquire  products  and  product  components  that  will  be  used  by  the 

project.  [PA166.IG101.SP101.N106] 


Examples  of  types  of  acquisition  include  the  following:  [pai66.igioi.spioi.nio7] 

•  Purchasing  commercial  off-the-shelf  (COTS)  products 

•  Obtaining  products  through  a  contractual  agreement 

•  Obtaining  products  from  an  in-house  vendor 

•  Obtaining  products  from  the  customer 

•  Combining  some  of  the  above  (e.g.,  contracting  for  a  modification  to  a  COTS 
product  or  having  another  part  of  the  business  enterprise  co-develop  products 
with  an  external  supplier) 


Typical  Work  Products 

1 .  List  of  the  acquisition  types  that  will  be  used  for  all  products  and 
product  components  to  be  acquired  [pai66.igioi.spioi.wioi] 


SP  1.2-1  Select  Suppliers 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet  the 
specified  requirements  and  established  criteria,  [pai66.igioi.spw2] 
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Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation  approaches  that  can  be  used  to 
select  suppliers,  [paib6.igioi.spio2.rioi] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  specified  requirements,  [paib6.igioi.spio2.rio2] 

Criteria  should  be  established  to  address  factors  that  are  important  to 

the  project.  [PAI66.IGIOI.SPIO2.NIOI] 

Examples  of  factors  include  the  following:  [pai66.igioi.spio2.nio3] 

•  Geographical  location  of  the  supplier 

•  Supplier’s  performance  records  on  similar  work 

•  Engineering  capabilities 

•  Staff  and  facilities  available  to  perform  the  work 

•  Prior  experience  in  similar  applications 

Typical  Work  Products 

1 .  List  of  candidate  suppliers  [pai66.igioi  spio2.wioi] 

2.  Preferred  supplier  list  [pai66.igioi.spio2.wio2] 

3.  Rationale  for  selection  of  suppliers  [pai66.igioi.spio2.wio3] 

4.  Advantages  and  disadvantages  of  candidate  suppliers 

[PA166.IG101.SP102.W104] 

5.  Evaluation  criteria  [pai66.igioi.spio2.wio5] 

6.  Solicitation  materials  and  requirements  [pai66.igioi.spio2.wio6] 

Subpractices 

1 .  Establish  and  document  criteria  for  evaluating  potential  suppliers. 

[PA166.IG101.SP102.SubP101] 

2.  Identify  potential  suppliers  and  distribute  solicitation  material  and 
requirements  to  them.  [PAi66.iGioi.spio2.subPio2] 

3.  Evaluate  proposals  according  to  evaluation  criteria. 

[PA166.IG101.SP102.SubP103] 

4.  Evaluate  risks  associated  with  each  proposed  supplier. 

[PA166.IG101.SP102.SubP104] 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  evaluating  project  risks.  [PAi66.iGi01.sp102.subPi04.Ri0i] 

5.  Evaluate  proposed  suppliers'  ability  to  perform  the  work. 

[PA166.IG101.SP102.SubP105] 
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Examples  of  methods  to  evaluate  the  proposed  supplier’s  ability  to  perform  the 
work  include  the  following:  [PAi66.iGi01.sp102.subPi05.Ni0i] 

•  Evaluation  of  prior  experience  in  similar  applications 

•  Evaluation  of  prior  performance  on  similar  work 

•  Evaluation  of  management  capabilities 

•  Capability  evaluations 

•  Evaluation  of  staff  available  to  perform  the  work 

•  Evaluation  of  available  facilities  and  resources 

•  Evaluation  of  the  project’s  ability  to  work  with  the  proposed  supplier 

6.  Select  the  supplier.  [PAi66.iGioi.spio2.subPio6] 


SP  1.3-1  Establish  Supplier  Agreements 

Establish  and  maintain  formal  agreements  with  the  supplier. 

[PA166.IG101.SP103] 

A  formal  agreement  is  any  legal  agreement  between  the  organization 
(representing  the  project)  and  the  supplier.  This  agreement  may  be  a 
contract,  a  license,  or  a  memorandum  of  agreement,  [pai66.igioi.spio3.nioi] 

Typical  Work  Products 

1 .  Statements  of  work  [pai66.igioi.spio3.wioi] 

2.  Contracts  [PAI66.IGi0i.SPi03.Wi02] 

3.  Memoranda  of  agreement  [pai66.igioi.spio3.wio3] 

4.  Licensing  agreement  [pai66.igioi.spio3.wio4] 

Subpractices 

1 .  Revise  the  requirements  to  be  fulfilled  by  the  supplier  to  reflect 
negotiations  with  the  supplier  when  necessary,  [paiss.igioi  spio3.subPioi] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  revising  requirements.  iPAi66.iGi01.sp103.subPi01.Rwi] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  changes  to  requirements. 

[PA166.IG101.SP103.SubP101.R102] 

2.  Document  what  the  project  will  provide  to  the  supplier. 

[PA166.1G101.SP103.SubP102] 

Include  the  following:  [PAi66.iGi01.sp103.subPi02.Ni0i] 

•  Project-furnished  facilities 
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•  Documentation 

•  Services 

3.  Document  the  supplier  agreement.  [PAi66.iGioi.spio3.subPio3] 

The  supplier  agreement  should  include  a  statement  of  work,  a  specification,  terms 
and  conditions,  a  list  of  deliverables,  a  schedule,  a  budget,  and  a  defined 
acceptance  process.  [PAi66.iGi01.sp103.subPi03.Ni0i] 

This  subpractice  typically  includes  the  following:  [PAi66.iGi01.sp103.subPi03.Ni02] 

•  Establishing  the  statement  of  work,  specification,  terms  and  conditions,  list  of 
deliverables,  schedule,  budget,  and  acceptance  process 

•  Identifying  who  from  the  project  and  supplier  are  responsible  and  authorized  to 
make  changes  to  the  supplier  agreement 

•  Identifying  how  requirements  changes  and  changes  to  the  supplier  agreement  are 
determined,  communicated,  and  addressed 

•  Identifying  standards  and  procedures  that  will  be  followed 

•  Identifying  critical  dependencies  between  the  project  and  the  supplier 

•  Identifying  the  type  and  depth  of  project  oversight  of  the  supplier,  procedures,  and 
evaluation  criteria  to  be  used  in  monitoring  supplier  performance 

•  Identifying  the  types  of  reviews  that  will  be  conducted  with  the  supplier 

•  Identifying  the  supplier’s  responsibilities  for  ongoing  maintenance  and  support  of 
the  acquired  products 

•  Identifying  warranty,  ownership,  and  usage  rights  for  the  acquired  products 

•  Identifying  acceptance  criteria 

4.  Ensure  all  parties  to  the  agreement  understand  and  agree  to  all 
requirements  before  implementing  the  agreement. 

[PA166.IG101.SP103.SubP104] 

5.  Revise  the  supplier  agreement  as  necessary.  [PAi66.iGioi.spio3.subPio5] 

6.  Revise  the  project’s  plans  and  commitments  as  necessary  to 
reflect  the  supplier  agreement.  [PAi66.iGioi.spio3.subPio6] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  revising  the  project  plan.  [PAi66.iGi01.sp103.subPi06.Ri0i] 


SG  2  Satisfy  Supplier  Agreements 


Agreements  with  the  suppliers  are  satisfied  by  both  the  project  and  the 

Supplier.  [PA166.IG102] 
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SP  2.1-1 


Review  COTS  Products 

Review  candidate  COTS  products  to  ensure  they  satisfy  the 
specified  requirements  that  are  covered  under  a  supplier 
agreement,  [pai66.igw2.spwi] 

In  the  event  that  COTS  products  are  desired,  care  in  evaluating  and 
selecting  these  products  and  the  vendor  may  be  critical  to  the  project. 

[PA166.IG102.SP101.N101] 

Typical  Work  Products 

1.  Trade  studies  [pai66.igio2.spioi.wioi] 

2.  Price  lists  [PA166.IG102.SP101.W102] 

3.  Evaluation  criteria  [pai66.igio2.spioi.wio3] 

4.  Supplier  performance  reports  [pai66.igio2.spioi.wio4] 

5.  Reviews  of  COTS  products  [pai66.igio2.spioi.wio5] 

Subpractices 

1 .  Develop  criteria  for  evaluating  COTS  products.  [PAi66.iGio2.spioi.subPioi] 

2.  Evaluate  candidate  COTS  products  against  the  associated 
requirements  and  criteria.  [PAi66.iGio2.spioi.subPio2] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  the  requirements  that  will  be  used  to  evaluate 
candidate  products.  [PAi66.iGi02.sp101.subPi02.Rwi] 

These  requirements  address  the  following:  [PAi66.iGi02.sp101.subPi02.Ni0i] 

•  Functionality,  performance,  quality,  and  reliability 

•  Terms  and  conditions  of  warranties  for  the  products 

•  Risk 

•  Suppliers'  responsibilities  for  ongoing  maintenance  and  support  of  the  products 

3.  Evaluate  the  impact  of  candidate  COTS  products  on  the  project's 
plans  and  commitments.  [PAi66.iGio2.spioi.subPio3] 

Evaluate  according  to  the  following:  [PAi66.iGio2.sp101.subPio3.Nioi] 

•  Cost  of  the  COTS  products 

•  Cost  and  effort  to  incorporate  the  COTS  products  into  the  project 

•  Security  requirements 

•  Benefits  and  impacts  that  may  result  from  future  product  releases 


240 


Project  Management,  Supplier  Agreement  Management 


CMMI-SW,  vl.1 
Continuous  Representation 


Future  product  releases  may  provide  additional  features  that  support  planned  or 
anticipated  enhancements  for  the  project,  but  may  also  result  in  the  supplier 
withdrawing  support  of  the  version  for  the  product  that  is  acquired  by  the  project, 

[PA166.IG102.SP101.SubP103.N102] 

4.  Assess  the  suppliers'  performance  and  ability  to  deliver. 

[PA166.IG102.SP101.SubP104] 

5.  Identify  risks  associated  with  the  selected  COTS  product  and  the 
supplier  agreement.  [PAi66.iGio2.spioi.subPio5] 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  identifying  project  risks.  [PAi66.iGi02.spw1.subPi05.Ri02] 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  project  risks.  [PAi66.iGio2.spw1.subPio5.Rioi] 

6.  Select  the  COTS  product  to  be  acquired.  [PAi66.iGio2.spioi.subPio6] 

In  some  cases,  selection  of  COTS  products  may  require  a  supplier  agreement  in 
addition  to  the  agreements  in  the  product’s  license.  [PAi66.iGi02.sp101.subPi06.Ni0i] 


Examples  of  agreements  with  COTS  suppliers  include  the  following: 

[PA166.IG102.SP101.SubP106.N102] 

•  Discounts  for  large  quantity  purchases 

•  Coverage  of  relevant  stakeholders  under  the  licensing  agreement,  including 
project  suppliers,  team  members,  and  the  project’s  customer 

•  Plans  for  future  enhancements 

•  On-site  support,  such  as  responses  to  queries  and  problem  reports 

•  Additional  capabilities  that  are  not  in  the  product 

•  Maintenance  support,  including  support  after  the  product  is  withdrawn  from 
general  availability 


7.  Plan  for  the  maintenance  of  the  COTS  product.  [PAi66.iGio2.spioi.sUbPio7] 


SP  2.2-1  Execute  the  Supplier  Agreement 

Perform  activities  with  the  supplier  as  specified  in  the  supplier 
agreement,  [pai66.igw2.spw2] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  projects  and  taking  corrective  action. 

[PA166.IG102.SP102.RW1] 

Typical  Work  Products 

1.  Supplier  progress  reports  and  performance  measures 

[PAi66.iGi02.sp102.w10i] 
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2.  Supplier  review  materials  and  reports  [pai66.igio2.spio2.wio3] 

3.  Action  items  tracked  to  closure  [pai66.igio2.spio2.wio4] 

4.  Documentation  of  product  and  document  deliveries 

[PA166.IG102.SP102.W105] 

Subpractices 

1 .  Monitor  supplier  progress  and  performance  (schedule,  effort,  cost, 
and  technical  performance)  as  defined  in  the  supplier  agreement. 

[PA166.IG102.SP1 02. SubPI  01] 

2.  Monitor  selected  supplier  processes  and  take  corrective  action 
when  necessary.  [PAi66.iGio2.spio2.subPio2] 


Examples  of  processes  to  be  monitored  are  quality  assurance  and  configuration 
management.  [PAi66.iGi02.sp102.subPi02.Ni0i] 


3.  Conduct  reviews  with  the  supplier  as  specified  in  the  supplier 
agreement.  [PAi66.iGio2.spio2.subPio3] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  conducting  reviews.  [PAi66.iGi02.sp102.subPi03.Ri0i] 

Reviews  cover  both  formal  and  informal  reviews  and  include  the  following  steps: 

[PA166.IG102.SP102.SubP103.N101] 

•  Preparing  for  the  review 

•  Ensuring  that  relevant  stakeholders  participate 

•  Conducting  the  review 

•  Identifying,  documenting,  and  tracking  all  action  items  to  closure 

•  Preparing  and  distributing  to  the  relevant  stakeholders  a  summary  report  of  the 
review 

4.  Conduct  technical  reviews  with  the  supplier  as  defined  in  the 
supplier  agreement.  [PAi66.iGio2.spio2.subPio4] 

Technical  reviews  typically  include  the  following:  [PAi66.iGio2.sp102.subPio4.Nioi] 

•  Providing  the  supplier  with  visibility  into  the  needs  and  desires  of  the  project’s 
customers  and  end  users,  as  appropriate 

•  Reviewing  the  supplier's  technical  activities  and  verifying  that  the  supplier’s 
interpretation  and  implementation  of  the  requirements  are  consistent  with  the 
project’s  interpretation 

•  Ensuring  that  technical  commitments  are  being  met  and  that  technical  issues  are 
communicated  and  resolved  in  a  timely  manner 

•  Obtaining  technical  information  about  the  supplier’s  products 

•  Providing  appropriate  technical  information  and  support  to  the  supplier 
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5.  Conduct  management  reviews  with  the  supplier  as  defined  in  the 
supplier  agreement.  [PAi66.iGio2.spio2.subPio5] 

Management  reviews  typically  include  the  following:  [PAi66.iGi02.sp102.subPi05.Ni0i] 

•  Reviewing  critical  dependencies 

•  Reviewing  project  risks  involving  the  supplier 

•  Reviewing  schedule  and  budget 

Technical  and  management  reviews  may  be  coordinated  and  held  jointly. 

[PA166.IG102.SP102.SubP105.N102] 

6.  Use  the  results  of  reviews  to  improve  the  supplier's  performance 
and  to  establish  and  nurture  long-term  relationships  with  preferred 

suppliers.  [PA166.IG102.SP102.SubP106] 

7.  Monitor  risks  involving  the  supplier  and  take  corrective  action  as 
necessary.  [PAi66.iGio2.spio2.subPio7] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  risks.  [PAi66.iGi02.sp102.subPi07.Ri0i] 

8.  Revise  the  supplier  agreement  and  project  plans  and  schedules  as 
necessary.  [PAi66.iGio2.spio2.subPio8] 


SP  2.3-1  Accept  the  Acquired  Product 

Ensure  that  the  supplier  agreement  is  satisfied  before  accepting 
the  acquired  product,  ipai66.igio2.spw3] 


Acceptance  reviews  and  tests  and  configuration  audits  should  be 
completed  before  accepting  the  product  as  defined  in  the  supplier 
agreement,  [pai66.igio2.spio3.nioi] 

Typical  Work  Products 

1 .  Acceptance  test  procedures  [pai66.igio2.spio3.wioi] 

2.  Acceptance  test  results  [PAi66.iGi02.sp103.w102] 

3.  Discrepancy  reports  or  corrective  action  plans  [pai66.igio2.spio3.wio3] 

Subpractices 

1.  Define  the  acceptance  procedures.  [PAi66.iGio2.spio3.subPioi] 

2.  Review  and  obtain  agreement  with  relevant  stakeholders  on  the 
acceptance  procedures  before  the  acceptance  review  or  test. 

[PA166.IG102.SP103.SubP102] 

3.  Verify  that  the  acquired  products  satisfy  their  requirements. 

[PA166.IG102.SP103.SubP103] 
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Refer  to  the  Verification  process  area  for  more  information  about 
verifying  products.  [PAi66.iGi02.sp103.subPi03.Ri0i] 


4.  Confirm  that  the  nontechnical  commitments  associated  with  the 
acquired  work  product  are  satisfied.  [PAi66.iGio2.spio3.subPio4] 

This  may  include  confirming  that  the  appropriate  license,  warranty,  ownership, 
usage,  and  support  or  maintenance  agreements  are  in  place  and  that  all 
supporting  materials  are  received.  [PAi66.iGio2.sp103.subPio4.Nioi] 

5.  Document  the  results  of  the  acceptance  review  or  test. 

[PA166.IG102.SP103.SubP105] 

6.  Establish  and  obtain  supplier  agreement  on  an  action  plan  for  any 
acquired  work  products  that  do  not  pass  their  acceptance  review  or 

test.  [PA166.IG102.SP103.SubP106] 

7.  Identify,  document,  and  track  action  items  to  closure. 

[PA166.IG102.SP103.SubP107] 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items.  [PAi66.iGi02.sp103.subPi07.Ri0i] 


SP  2.4-1  Transition  Products 

Transition  the  acquired  products  from  the  supplier  to  the  project. 

[PA166.IG102.SP104] 


Before  the  acquired  product  is  transferred  to  the  project  for  integration, 
appropriate  planning  and  evaluation  should  occur  to  ensure  a  smooth 

transition.  [PA166.IG102.SP104.N101] 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  integrating  the  acquired  products,  [paib6.igio2.spio4.nioi.rioi] 

Typical  Work  Products 

1.  Transition  plans  [PAi66.iGi02.sp104.w10i] 

2.  Training  reports  [PAi66.iGi02.sp104.w102] 

3.  Support  and  maintenance  reports  [pai66.igio2.spio4.wio3] 

Subpractices 

1 .  Ensure  that  there  are  appropriate  facilities  to  receive,  store,  use, 
and  maintain  the  acquired  products.  [PAi66.iGio2.spio4.subPioi] 

2.  Ensure  that  appropriate  training  is  provided  for  those  involved  in 
receiving,  storing,  using,  and  maintaining  the  acquired  products. 

[PA166.IG102.SP104.SubP102] 
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3.  Ensure  that  storing,  distributing,  and  using  the  acquired  products 
are  performed  according  to  the  terms  and  conditions  specified  in 
the  supplier  agreement  or  license.  [PAi66.iGio2.spio4.subPio3] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  supplier  agreement  management 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  supplier  agreement  management  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing, 
maintaining,  and  satisfying  supplier  agreements.  [pai66.elioii 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  supplier 
agreement  management  process,  [gpiov 


Elaboration: 

Typically,  portions  of  this  plan  for  performing  the  supplier  agreement 
management  process  are  a  part  of  the  project  plan  as  described  in  the 
Project  Planning  process  area.  Often,  however,  some  portions  of  the 
plan  reside  outside  of  the  project  with  an  independent  group,  such  as 
contract  management.  [pai66.elho] 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  supplier  agreement 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  igpios] 


Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pai66.elio2] 

•  Preferred  supplier  lists 

•  Requirements  tracking  programs 

•  Project  management  and  scheduling  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
supplier  agreement  management  process,  [gpiosj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  supplier  agreement 
management  process  as  needed.  [gpio7i 


Elaboration: 

Examples  of  training  topics  include  the  following:  [pai66.elio3] 

•  Regulations  and  business  practices  related  to  negotiating  and  working  with 
suppliers 

•  Acquisition  planning  and  preparation 

•  COTS  products  acquisition 

•  Supplier  evaluation  and  selection 

•  Negotiation  and  conflict  resolution 

•  Supplier  management 

•  Testing  and  transitioning  of  acquired  products 

•  Receiving,  storing,  using,  and  maintaining  acquired  products 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  supplier  agreement 
management  process  under  appropriate  levels  of  configuration 
management,  [g pioy 
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Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai66.elio4] 

•  Statements  of  work 

•  Supplier  agreements 

•  Memoranda  of  agreement 

•  Subcontracts 

•  Preferred  supplier  lists 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  supplier 
agreement  management  process  as  planned.  [gpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai66.elio9] 

•  Establishing  criteria  for  evaluation  of  potential  suppliers 

•  Reviewing  potential  suppliers 

•  Establishing  supplier  agreements 

•  Resolving  issues  with  suppliers 

•  Reviewing  supplier  performance 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  supplier  agreement  management  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuoj 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA166.EL105] 

•  Number  of  changes  made  to  the  requirements  for  the  supplier 

•  Cost  and  schedule  variance  per  supplier  agreement 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  supplier  agreement 
management  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance,  [gpusi 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai66.eho6] 

•  Establishing  and  maintaining  supplier  agreements 

•  Satisfying  supplier  agreements 

Examples  of  work  products  reviewed  include  the  following:  [pai66.elios] 

•  Plan  for  Supplier  Agreement  Management 

•  Supplier  agreements 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  supplier  agreement 
management  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  supplier 
agreement  management  process,  [gpiui 

Collect  Improvement  Information 

GG  4  Institution 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  supplier  agreement  management  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  supplier 
agreement  management  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP118] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  supplier  agreement  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  igpusi 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  supplier  agreement 
management  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization.  igpi2S] 


GP  5.2  Correct  Root  Causes  of  Problems 

identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  supplier  agreement  management  process.  [GP1211 
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INTEGRATED  PROJECT  MANAGEMENT 

Project  Management 


Purpose 


The  purpose  of  Integrated  Project  Management  is  to  establish  and 
manage  the  project  and  the  involvement  of  the  relevant  stakeholders 
according  to  an  integrated  and  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes.  [pai67] 


Introductory  Notes 


Integrated  Project  Management  involves  the  following:  [pais7nio2] 

•  Establishing  the  project's  defined  process  by  tailoring  the 
organization's  set  of  standard  processes 

•  Managing  the  project  using  the  project’s  defined  process 

•  Using  and  contributing  to  the  organizational  process  assets 

•  Enabling  relevant  stakeholders’  concerns  to  be  identified, 
considered,  and,  when  appropriate,  addressed  during  the 
development  of  the  product 

•  Ensuring  that  the  relevant  stakeholders  perform  their  tasks  in  a 
coordinated  and  timely  manner  (1)  to  address  product  and  product- 
component  requirements,  plans,  objectives,  issues,  and  risks;  (2) 
to  fulfill  their  commitments;  and  (3)  to  identify,  track,  and  resolve 
issues 

The  integrated  and  defined  process  that  is  tailored  from  the 

organization’s  set  of  standard  processes  is  called  the  project’s  defined 

process,  [paw.niio] 


Managing  the  project’s  effort,  cost,  schedule,  staffing,  risks,  and  other 
factors  is  tied  to  the  tasks  of  the  project's  defined  process.  The 
implementation  and  management  of  the  project's  defined  process  are 
typically  described  in  the  project  plan.  Certain  activities  may  be  covered 
in  other  plans  that  affect  the  project,  such  as  the  quality  assurance  plan, 
risk  management  strategy,  and  the  configuration  management  plan. 

[PA167.N103] 


Since  the  defined  process  for  each  project  is  tailored  from  the 
organization's  set  of  standard  processes,  variability  among  projects  is 
typically  reduced  and  projects  can  more  easily  share  process  assets, 
data,  and  lessons  learned,  [paw.nicm] 
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This  process  area  also  addresses  the  coordination  of  all  activities 
associated  with  the  project  including  the  following:  [pai67.nio5] 

•  Technical  activities  such  as  requirements  development,  design, 
and  verification 

•  Support  activities  such  as  configuration  management, 
documentation,  marketing,  and  training 

The  working  interfaces  and  interactions  among  relevant  stakeholders 
internal  and  external  to  the  project  are  planned  and  managed  to  ensure 
the  quality  and  integrity  of  the  entire  product.  Relevant  stakeholders 
participate,  as  appropriate,  in  defining  the  project’s  defined  process  and 
the  project  plan.  Reviews  and  exchanges  are  regularly  conducted  with 
the  relevant  stakeholders  and  coordination  issues  receive  appropriate 
attention.  Reviews  and  exchanges  are  regularly  conducted  with  the 
relevant  stakeholders  to  ensure  that  coordination  issues  receive 
appropriate  attention  and  everyone  involved  with  the  project  is 
appropriately  aware  of  the  status,  plans,  and  activities.  In  defining  the 
project’s  defined  process,  formal  interfaces  are  created  as  necessary  to 
ensure  that  appropriate  coordination  and  collaboration  occurs,  [paw.nw] 

See  Chapter  3  for  an  explanation  of  how  “relevant  stakeholder”  is  used 

in  the  CMMI  Product  Suite.  [PA167.N106] 

This  process  area  applies  in  any  organizational  structure,  including 
projects  that  are  structured  as  line  organizations,  matrix  organizations, 
or  integrated  teams.  The  terminology  should  be  appropriately 
interpreted  for  the  organizational  structure  in  place,  [paw.nios] 

If  you  are  using  the  continuous  representation,  the  first  specific  goal  in 
this  process  area  may  be  redundant  when  applying  the  capability  level 
3  generic  practices  to  project-related  process  areas.  However,  the 
specific  practices,  subpractices,  and  notes  will  provide  many  details  that 
will  assist  you  with  this  application.  [pai67.nio9] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
planning  the  project.  [paw.rioij 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project.  [paib7.rio2] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  relevant  stakeholders  and  their  appropriate  involvement  in 
the  project.  [pai67.rio3] 

Refer  to  the  Verification  process  area  for  more  information  about  peer 
reviews.  [paib7.rio4] 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets.  [paib7.rios] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  measuring  and  analyzing 
processes.  [pai67.riob] 

Specific  Goals 

SG  1  Use  the  Project’s  Defined  Process  [pai67  igioi] 

The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes. 

SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders  [paw .10102] 

Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  is 
conducted. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 
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Practice-to-Goal  Relationship  Table 

SG  1  Use  the  Project’s  Defined  Process  [pai67.igioi] 

SP  1.1-1  Establish  the  Project’s  Defined  Process 

SP  1 .2-1  Use  Organizational  Process  Assets  for  Planning  Project  Activities 
SP  1.3-1  Integrate  Plans 

SP  1.4-1  Manage  the  Project  Using  the  Integrated  Plans 
SP  1 .5-1  Contribute  to  the  Organizational  Process  Assets 

SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders  [pai67.igio2] 

SP  2.1-1  Manage  Stakeholder  Involvement 

SP  2.2-1  Manage  Dependencies 

SP  2.3-1  Resolve  Coordination  Issues 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clioaglioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Ouantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Ouantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 

SG  1  Use  the  Project’s  Defined  Process 

The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes.  [pai67.igioii 

The  project's  defined  process  must  include  those  processes  from  the 
organization's  set  of  standard  processes  that  address  all  processes 
necessary  to  develop  and  maintain  the  product.  The  product-related 
life-cycle  processes,  such  as  the  manufacturing  and  support  processes, 
are  developed  concurrently  with  the  product,  [pai67.igioi.nioi] 
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SP  1.1-1 


Establish  the  Project’s  Defined  Process 

Establish  and  maintain  the  project's  defined  process,  [pai67.igioi.spwi] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  [pai67.igwi.spwi.rioi] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives. 

[PA167.IGW1.SPW1.R102] 

The  project's  defined  process  consists  of  defined  processes  that  form 
an  integrated,  coherent  life  cycle  for  the  project,  [pai67.igioi.spioi.nioi] 

The  project’s  defined  process  covers  all  the  processes  needed  by  the 
project,  including  those  processes  addressed  by  the  process  areas  at 
maturity  level  2.  [pai67.igioi.spioi.mo3] 

The  project's  defined  process  should  satisfy  the  project's  contractual 
and  operational  needs,  opportunities,  and  constraints.  It  is  designed  to 
provide  a  best  fit  for  the  project’s  needs.  A  project's  defined  process  is 
based  on  the  following:  [pai67.igioi.spioi.nio2] 

•  Customer  requirements 

•  Product  and  product-component  requirements 

•  Commitments 

•  Organizational  process  needs  and  objectives 

•  Operational  environment 

•  Business  environment 

Typical  Work  Products 

1.  The  project’s  defined  process  [pai67.igioi.spioi.wioi] 

Subpractices 

1 .  Select  a  life-cycle  model  from  those  available  from  the 
organizational  process  assets.  [PAi67.iGioi.spioi.subPioi] 

2.  Select  the  standard  processes  from  the  organization's  set  of 
standard  processes  that  best  fit  the  needs  of  the  project. 

[PA167.IG101.SP101.SubP102] 

3.  Tailor  the  organization's  set  of  standard  processes  and  other 
organizational  process  assets  according  to  the  tailoring  guidelines 
to  produce  the  project’s  defined  process.  [pai67.igioi ,spioi.subPio3] 
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Sometimes  the  available  life-cycle  models  and  standard  processes  are 
inadequate  to  meet  a  specific  project’s  needs.  Sometimes  the  project  will  be 
unable  to  produce  required  work  products  or  measures.  In  such  circumstances, 
the  project  will  need  to  seek  approval  to  deviate  from  what  is  required  by  the 
organization.  Waivers  are  provided  for  this  purpose.  [PAi67.iGi01.sp101.subPi03.Ni0i] 

4.  Use  other  artifacts  from  the  organization's  process  asset  library  as 
appropriate.  [PAi67.iGioi.spioi.subPio4] 

Other  artifacts  may  include  the  following:  [PAie7.iGi01.sp101.subPi04.Ni0i] 

•  Lessons-learned  documents 

•  Templates 

•  Example  documents 

•  Estimating  models 

5.  Document  the  project's  defined  process.  [PAi67.iGioi.spioi.subPio5] 

The  project's  defined  process  covers  all  the  engineering,  management,  and 
support  activities  for  the  project  and  its  interfaces  to  relevant  stakeholders. 

[PA167.IG101.SP101.SubP105.N101] 

Examples  of  project  activities  include  the  following:  [PAi67.iGio1.sp101.subPio5.Nio2] 

•  Project  planning 

•  Project  monitoring  and  controlling 

•  Requirements  development 

•  Requirements  management 

•  Design  and  implementation 

•  Verification  and  validation 

•  Product  integration 

•  Supplier  agreement  management 

•  Configuration  management 

•  Quality  assurance 

6.  Conduct  peer  reviews  of  the  project's  defined  process. 

[PA167.IG101.SP101.SubP106] 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews.  [PAi67.iGioi.spioi.subPio6.Rioi] 

7.  Revise  the  project's  defined  process  as  necessary. 

[PA167.IG101.SP101.SubP107] 
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SP  1.2-1 


Use  Organizational  Process  Assets  for  Planning  Project  Activities 

Use  the  organizational  process  assets  and  measurement 
repository  for  estimating  and  planning  the  project’s  activities. 

[PA167.IG101.SP102] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and  the  organization’s 
measurement  repository,  [pai67.igioi.spio2.rioi] 

Typical  Work  Products 

1.  Project  estimates  [pai67.igioi.spio2.wioi] 

2.  PrOjeCt  planS  [PAI67.IGIOI.SPIO2.WIO2] 

Subpractices 

1 .  Base  the  activities  for  estimating  and  planning  on  the  tasks  and 
work  products  of  the  project's  defined  process.  [PAi67.iGioi.spio2.subPioi] 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project's  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  is  a  basis  for  developing  a  realistic  plan.  [PAi67.iGi01.sp102.subPi01.Ni0i] 

2.  Use  the  organization’s  measurement  repository  in  estimating  the 
project’s  planning  parameters.  [PAi67.iGioi.spio2.subPio2] 

This  estimate  typically  includes  the  following:  [PAi67.iGio1.sp102.subPio2.Nioi] 

•  Using  appropriate  historical  data  from  this  project  or  similar  projects 

•  Accounting  for  and  recording  similarities  and  differences  between  the  current 
project  and  those  projects  whose  historical  data  will  be  used 

•  Independently  validating  the  historical  data 

•  Recording  the  reasoning,  assumptions,  and  rationale  used  to  select  the  historical 
data 

Examples  of  parameters  that  are  considered  for  similarities  and  differences 
include  the  following:  [PAi67.iGi01.sp102.subPi02.Ni02] 

•  Work  product  and  task  attributes 

•  Application  domain 

•  Design  approach 

•  Operational  environment 

•  Experience  of  the  people 
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Examples  of  data  contained  in  the  organization’s  measurement  repository  include 
the  following:  [PAi67.iGi01.sp102.subPi02.Ni03] 

•  Size  of  work  products  or  other  work  product  attributes 

•  Effort 

•  Cost 

•  Schedule 

•  Staffing 

•  Defects 


SP  1.3-1  Integrate  Plans 

Integrate  the  project  plan  and  the  other  plans  that  affect  the 
project  to  describe  the  project’s  defined  process.  ipai67.igioi.spio3] 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
establishing  and  maintaining  a  project  plan,  [pai67.igwi.spw3.rioi] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  organizational  process  assets  and,  in  particular,  the 
organization’s  measurement  repository,  [pai67.igwi.spw3.rw2i 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures  and  measurement  activities  and 
using  analytic  techniques,  [pai67.igwi.spw3.rw3] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  analyzing  risks,  [pai67.igwi.spw3.rw4] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives. 

[PA167.IGW1.SPW3.RW5] 


This  specific  practice  extends  the  specific  practices  for  establishing  and 
maintaining  a  project  plan  to  address  additional  planning  activities  such 
as  incorporating  the  project’s  defined  process,  coordinating  with 
relevant  stakeholders,  using  organizational  process  assets, 
incorporating  plans  for  peer  reviews,  and  establishing  objective  entry 
and  exit  criteria  for  tasks,  [pai67.igioi.spio3.nioi] 

The  development  of  the  project  plan  should  account  for  current  and 
projected  needs,  objectives,  and  requirements  of  the  organization, 
customer,  and  end  users,  as  appropriate,  [pai67.igioi.spio3.nio2] 

Typical  Work  Products 

1.  Integrated  plans  [pai67.igioi.spio3.wioi] 


Project  Management,  Integrated  Project  Management 


257 


CMMI-SW,  vl.1 
Continuous  Representation 

Subpractices 

1 .  Integrate  other  plans  that  affect  the  project  with  the  project  plan. 

[PA167.IG101.SP103.SubP101] 

Other  plans  that  affect  the  project  may  include  the  following: 

[PA167.IG101.SP103.SubP101.N101] 

•  Quality  assurance  plans 

•  Configuration  management  plans 

•  Risk  management  strategy 

•  Documentation  plans 

2.  Incorporate  into  the  project  plan  the  definitions  of  measures  and 
measurement  activities  for  managing  the  project. 

[PA1 67.IG1 01  .SP1 03.SubP1 02] 

Examples  of  measures  that  would  be  incorporated  include  the  following: 

[PA167.IG101.SP103.SubP102.N101] 

•  Organization’s  common  set  of  measures 

•  Additional  project-specific  measures 

3.  Identify  and  analyze  product  and  project  interface  risks. 

[PA167.IG101.SP103.SubP103] 

Examples  of  product  and  project  interface  risks  include  the  following: 

[PA167.IG101.SP103.SubP103.N101] 

•  Incomplete  interface  descriptions 

•  Unavailability  of  tools  or  test  equipment 

•  Availability  of  COTS  components 

•  Inadequate  or  ineffective  team  interfaces 

4.  Schedule  the  tasks  in  a  sequence  that  accounts  for  critical 
development  factors  and  project  risks.  [PAi67.iGioi.spio3.subPio4] 

Examples  of  factors  considered  in  scheduling  include  the  following: 

[PA167.IG101.SP103.SubP104.N101] 

•  Size  and  complexity  of  the  tasks 

•  Integration  and  test  issues 

•  Needs  of  the  customer  and  end  users 

•  Availability  of  critical  resources 

•  Availability  of  key  personnel 

5.  Incorporate  the  plans  for  performing  peer  reviews  on  the  work 
products  of  the  project's  defined  process.  [PAi67.iGioi.spio3.subPio5] 
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Refer  to  the  Verification  process  area  for  more  information  about 
peer  reviews.  [PAi67.iGi01.sp103.subPi05.Ri0i] 

6.  Incorporate  the  training  needed  to  perform  the  project’s  defined 
process  in  the  project’s  training  plans.  [PAi67.iGioi.spio3.subPioe] 

This  task  typically  involves  negotiating  with  the  organizational  training  group  the 
support  they  will  provide.  [PAi67.iGioi.spio3.subPioe.Nioi] 

7.  Establish  objective  entry  and  exit  criteria  to  authorize  the  initiation 
and  completion  of  the  tasks  described  in  the  work  breakdown 

structure  (WBS).  [PA1 67.IG1 01  .SP1 03.SubP1 07] 

Refer  to  the  Project  Planning  process  area  for  more  information 

about  the  WBS.  [PA167.IG101.SP103.SubP107.R101] 

8.  Ensure  that  the  project  plan  is  appropriately  compatible  with  the 
plans  of  relevant  stakeholders.  [PAi67.iGioi.spio3.subPios] 

Typically  the  plan  and  changes  to  the  plan  will  be  reviewed  for  compatibility. 

[PA167.IG101.SP103.SubP108.N101] 

9.  Identify  how  conflicts  will  be  resolved  that  arise  among  relevant 
stakeholders.  [PAi67.iGioi.spio3.subPio9] 


SP  1.4-1  Manage  the  Project  Using  the  Integrated  Plans 

Manage  the  project  using  the  project  plan,  the  other  plans  that 
affect  the  project,  and  the  project’s  defined  process.  [paib7.igioi.spio4] 


Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  [pai67.igioi.spio4.rwi] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  organizational  process  needs  and  objectives  and 
coordinating  process-improvement  activities  with  the  rest  of  the 
organization,  ipai67.igioi.spio4.rio2] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
managing  risks,  [pai67.igioi.spio4.rio3] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project. 

[PA167.IG101.SP104.R104] 

Typical  Work  Products 

1 .  Work  products  created  by  performing  the  project’s  defined  process 

[PA167.iG101.SP104.W101] 
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2.  Collected  measures  (“actuals”)  and  progress  records  or  reports 

[PA167.IG101.SP104.W102] 

3.  Revised  requirements,  plans,  and  commitments  [pai67.igioi.spio4.wio3] 

4.  Integrated  plans  [pai67.igioi.spio4.wio4] 

Subpractices 

1 .  Implement  the  project’s  defined  process  using  the  organization's 
process  asset  library.  [PAw.iGioi.spm.subPioi] 

This  task  typically  includes  the  following:  [PAi67.iGioi.spio4.subPioi.Nioi] 

•  Incorporating  artifacts  from  the  organization’s  process  asset  library  into  the  project 
as  appropriate 

•  Using  lessons  learned  from  the  organization’s  process  asset  library  to  manage  the 
project 

2.  Monitor  and  control  the  project’s  activities  and  work  products  using 
the  project’s  defined  process,  project  plan,  and  other  plans  that 
affect  the  project.  [PAi67.iGioi.spio4.subPio2] 

This  task  typically  includes  the  following:  [PAi67.iGi01.sp104.subPi02.Ni0i] 

•  Using  the  defined  entry  and  exit  criteria  to  authorize  the  initiation  and  determine 
the  completion  of  the  tasks 

•  Monitoring  the  activities  that  could  significantly  affect  the  actual  values  of  the 
project’s  planning  parameters 

•  Tracking  the  project’s  planning  parameters  using  measurable  thresholds  that  will 
trigger  investigation  and  appropriate  actions 

•  Monitoring  product  and  project  interface  risks 

•  Managing  external  and  internal  commitments  based  on  the  plans  for  the  tasks  and 
work  products  of  implementing  the  project's  defined  process 

An  understanding  of  the  relationships  among  the  various  tasks  and  work  products 
of  the  project's  defined  process,  and  of  the  roles  to  be  performed  by  the  relevant 
stakeholders,  along  with  well-defined  control  mechanisms  (e.g.,  peer  reviews), 
achieves  better  visibility  into  the  project’s  performance  and  better  control  of  the 

project.  [PA167.IG101.SP104.SubP102.N102] 

3.  Obtain  and  analyze  the  selected  measures  to  manage  the  project 
and  support  the  organization’s  needs.  [PAi67.iGioi.spio4.subPio3] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  a  process  for  obtaining  and  analyzing 

meaSUreS.  [PA167.IG101.SP104.SubP103.R101] 

4.  Periodically  review  the  adequacy  of  the  environment  to  meet  the 
project’s  needs  and  to  support  coordination.  [PAi67.iGioi.spio4.subPio4] 
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Examples  of  actions  that  might  be  taken  include  the  following: 

[PA167.IG101.SP104.SubP104.N101] 

•  Adding  new  tools 

•  Acquiring  additional  networks,  equipment,  training,  and  support 


5.  Periodically  review  and  align  the  project’s  performance  with  the 
current  and  anticipated  needs,  objectives,  and  requirements  of  the 
organization,  customer,  and  end  users,  as  appropriate. 

[PA1 67.IG1 01  .SP1 04.SubP1 05] 


This  review  includes  alignment  with  the  organizational  process  needs  and 

objectives.  [PA167.IG101.SP104.SubP105.N101] 


Examples  of  actions  that  achieve  alignment  include  the  following: 

[PA167.IG101.SP104.SubP105.N102] 

•  Accelerating  the  schedule,  with  appropriate  adjustments  to  other  planning 
parameters  and  the  project  risks 

•  Changing  the  requirements  in  response  to  a  change  in  market  opportunities  or 
customer  and  end-user  needs 

•  Terminating  the  project 


SP  1.5-1  Contribute  to  the  Organizational  Process  Assets 

Contribute  work  products,  measures,  and  documented 
experiences  to  the  organizational  process  assets,  [pai67.igioi.spws] 

Refer  to  the  Organizational  Process  Focus  process  area  for  more 
information  about  process-improvement  proposals,  [pm67.igioi.spios.rioi] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  the  organization’s 
measurement  repository,  and  the  organization’s  process  asset  library. 

[PA167.IG101.SP10S.R102] 

This  specific  practice  addresses  collecting  information  from  processes 
in  the  project’s  defined  process,  [pai67.igioi.spio5.nioi] 

Typical  Work  Products 

1 .  Proposed  improvements  to  the  organizational  process  assets 

[PA167.IG101.SP105.W101] 

2.  Actual  process  and  product  measures  collected  from  the  project 

[PA167.IG101.SP105.W102] 

3.  Documentation  (e.g.,  exemplary  process  descriptions,  plans, 
training  modules,  checklists,  and  lessons  learned)  [pai67.igioi  spio5.wio3] 
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Subpractices 

1 .  Propose  improvements  to  the  organizational  process  assets. 

[PA167.IG101.SP105.SubP101] 

2.  Store  process  and  product  measures  in  the  organization’s 
measurement  repository.  [PAi67.iGioi.spio5.subPio2] 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  recording  planning  and  re-planning  data. 

[PA167.IG101.SP105.SubP102.R101] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  recording  measures.  [PAi67.iGi01.spw5.subPi02.Ri02] 

This  typically  includes  the  following:  [PAi67.iGio1.sp105.subPio2.Nioi] 

•  Planning  data 

•  Re-planning  data 

•  Measures 

Examples  of  data  recorded  by  the  project  include  the  following: 

[PA167.IG101.SP105.SubP102.N102] 

•  Task  descriptions 

•  Assumptions 

•  Estimates 

•  Revised  estimates 

•  Definitions  of  recorded  data  and  measures 

•  Measures 

•  Context  information  that  relates  the  measures  to  the  activities  performed  and  work 
products  produced 

•  Associated  information  needed  to  reconstruct  the  estimates,  assess  their 
reasonableness,  and  derive  estimates  for  new  work 

3.  Submit  documentation  for  possible  inclusion  in  the  organization's 
process  asset  library.  [PAi67.iGioi.spios.subPio3] 

Examples  of  documentation  include  the  following:  [PAi67.iGi01.sp105.subPi03.Ni0i] 

•  Exemplary  process  descriptions 

•  Training  modules 

•  Exemplary  plans 

•  Checklists 

4.  Document  lessons  learned  from  the  project  for  inclusion  in  the 
organization's  process  asset  library.  [PAi67.iGioi.spio5.subPio4] 
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SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 


Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  is 
conducted.  [pai67.igio2] 


SP  2.1-1  Manage  Stakeholder  Involvement 

Manage  the  involvement  of  the  relevant  stakeholders  in  the 

project.  [PA167.IG102.SP101] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  on 
establishing  and  maintaining  commitments,  [paib7.igio2.spioi.rioi] 

Typical  Work  Products 

1 .  Agendas  and  schedules  for  collaborative  activities  [pai67.igio2.spioi.wioi] 

2.  Documented  issues  (e.g.,  issues  with  customer  requirements, 
product  and  product-component  requirements,  product 
architecture,  and  product  design)  [pai67.igio2.spioi.wio2] 

3.  Recommendations  for  resolving  relevant  stakeholder  issues 

[PA167.IG102.SP101.W103] 

Subpractices 

1 .  Coordinate  with  the  relevant  stakeholders  who  should  participate  in 
the  project’s  activities.  [PAi67.iGio2.spioi.subPioi] 

The  relevant  stakeholders  should  already  be  identified  in  the  project  plan. 

[PA167.IG102.SP101.SubP101.N101] 

2.  Ensure  that  work  products  that  are  produced  to  satisfy 
commitments  meet  the  requirements  of  the  recipient  projects. 

[PA167.IG102.SP101.SubP103] 


Refer  to  the  Verification  process  area  for  more  information  about 
determining  acceptability  of  work  products.  [PAi67.iGi02.sp101.subPi03.Ri0i] 


This  task  typically  includes  the  following:  [PAi67.iGi02.sp101.subPi03.Ni0i] 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced 
by  relevant  stakeholders 

•  Reviewing,  demonstrating,  or  testing,  as  appropriate,  each  work  product  produced 
by  the  project  for  other  projects  with  representatives  of  the  projects  receiving  the 
work  product 

•  Resolving  issues  related  to  the  acceptance  of  the  work  products 
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3.  Develop  recommendations  and  coordinate  the  actions  to  resolve 
misunderstandings  and  problems  with  the  product  and  product- 
component  requirements,  product  and  product-component 
architecture,  and  product  and  product-component  design. 

[PA167.IG102.SP101.SubP104] 


SP  2.2-1  Manage  Dependencies 

Participate  with  relevant  stakeholders  to  identify,  negotiate,  and 
track  critical  dependencies,  ipai67.igio2.spw2] 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  stakeholders  and  their  appropriate  involvement  and  about 
establishing  and  maintaining  commitments,  [pm67.igio2.spio2.rwi] 

Typical  Work  Products 

1 .  Defects,  issues,  and  action  items  resulting  from  reviews  with 
relevant  stakeholders  ipai67.igio2.spio2.wio2] 

2.  Critical  dependencies  [pai67.igio2.spio2.wio3] 

3.  Commitments  to  address  critical  dependencies  [pai67.igio2.spio2.wio4] 

4.  Status  of  critical  dependencies  [pai67.igio2.spio2.wios] 

Subpractices 

1 .  Conduct  reviews  with  relevant  stakeholders.  [PAi67.iGio2.spio2.subPioi] 

2.  Identify  each  critical  dependency.  [PAi67.iGio2.spio2.subPio2] 

3.  Establish  need  dates  and  plan  dates  for  each  critical  dependency 
based  on  the  project  schedule.  [PAi67.iGio2.spio2.subPio3] 

4.  Review  and  get  agreement  on  the  commitments  to  address  each 
critical  dependency  with  the  people  responsible  for  providing  the 
work  product  and  the  people  receiving  the  work  product. 

[PA1 67.IG1 02.SP1 02.SubP1 04] 

5.  Document  the  critical  dependencies  and  commitments. 

[PA1 67.IG1 02.SP1 02.SubP1 05] 

Documentation  of  commitments  typically  includes  the  following: 

[PA167.IG102.SP102.SubP105.N101] 

•  Describing  the  commitment 

•  Identifying  who  made  the  commitment 

•  Identifying  who  is  responsible  for  satisfying  the  commitment 

•  Specifying  when  the  commitment  will  be  satisfied 

•  Specifying  the  criteria  for  determining  if  the  commitment  has  been  satisfied 
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6.  Track  the  critical  dependencies  and  commitments  and  take 

corrective  action  as  appropriate.  [PAi67.iGio2.spio2.subPio6] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 

information  about  tracking  commitments.  [PAi67.iGi02.sp102.subPi06.Ri0i] 

Tracking  the  critical  dependencies  typically  includes  the  following: 

[PA167.IG102.SP102.SubP106.N101] 

•  Evaluating  the  effects  of  late  and  early  completion  for  impacts  on  future  activities 
and  milestones 

•  Resolving  actual  and  potential  problems  with  the  responsible  people  where 
possible 

•  Escalating  to  the  appropriate  managers  the  actual  and  potential  problems  not 
resolvable  with  the  responsible  people 


SP  2.3-1  Resolve  Coordination  Issues 

Resolve  issues  with  relevant  stakeholders,  [pai67.igw2.spw3] 

Examples  of  coordination  issues  include  the  following:  [pai67.igio2.spio3.nioi] 

•  Late  critical  dependencies  and  commitments 

•  Product  and  product-component  requirements  and  design  defects 

•  Product-level  problems 

•  Unavailability  of  critical  resources  or  personnel 


Typical  Work  Products 

1 .  Relevant  stakeholder  coordination  issues  [PAi67.iGi02.sp103.w10i] 

2.  Status  of  relevant  stakeholder  coordination  issues  [pai67.igio2.spio3.wio2] 

Subpractices 

1 .  Identify  and  document  issues.  [PAi67.iGio2.spio3.subPioi] 

2.  Communicate  issues  to  the  relevant  stakeholders. 

[PA167.IG102.SP103.SubP102] 

3.  Resolve  issues  with  the  relevant  stakeholders.  [PAi67.iGio2.spio3.subPio3] 

4.  Escalate  to  the  appropriate  managers  those  issues  not  resolvable 
with  the  relevant  stakeholders.  [PAi67.iGio2.spio3.subPio4] 

5.  Track  the  issues  to  closure.  [PAi67.iGio2.spio3.subPio5] 

6.  Communicate  with  the  relevant  stakeholders  on  the  status  and 
resolution  of  the  issues.  [PAi67.iGio2.spio3.subPio6] 
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Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  integrated  project  management 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  igpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  integrated  project  management  process,  [g pio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  using  the 
project's  defined  process  and  coordinating  and  collaborating  with 
relevant  stakeholders.  [pai67.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  integrated 
project  management  process.  [gpio4} 


Elaboration: 

Typically,  this  plan  for  performing  the  integrated  project  management 
process  is  a  part  of  the  project  plan  as  described  in  the  Project  Planning 
process  area,  [paw.elw] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  integrated  project 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  igpiosj 
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Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pais7.elio2] 

•  Problem-tracking  and  trouble-reporting  packages 

•  Groupware 

•  Video  conferencing 

•  Integrated  decision  database 

•  Integrated  product  support  environments 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
integrated  project  management  process,  [gpiob] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  integrated  project 
management  process  as  needed,  [gpwi 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pai67.elio3] 

•  Tailoring  the  organization’s  set  of  standard  processes  to  meet  the  needs  of  the 
project 

•  Procedures  for  managing  the  project  based  on  the  project’s  defined  process 

•  Using  the  organization’s  measurement  repository 

•  Using  the  organizational  process  assets 

•  Integrated  management 

•  Intergroup  coordination 

•  Group  problem  solving 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  integrated  project 
management  process  under  appropriate  levels  of  configuration 
management,  [GPmi 
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Elaboration: 


Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai67.elio4] 

•  The  project’s  defined  process 

•  Project  plans 

•  Other  plans  that  affect  the  project 

•  Integrated  plans 

•  Actual  process  and  product  measures  collected  from  the  project 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  integrated 
project  management  process  as  planned,  [gpvmi 


Elaboration: 

This  generic  practice  is  different  from  managing  stakeholder 
involvement  for  the  project,  which  is  covered  by  specific  practices  within 
this  process  area,  [paw.elios] 


Examples  of  activities  for  stakeholder  involvement  include:  [pai67.elhoi 

•  Resolving  issues  about  the  tailoring  of  the  organizational  process  assets 

•  Resolving  issues  among  the  project  plan  and  the  other  plans  that  affect  the 
project 

•  Reviewing  project  performance  to  align  with  current  and  projected  needs, 
objectives,  and  requirements 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  integrated  project  management  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gphoj 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA167.EL105] 

•  Number  of  changes  to  the  project's  defined  process 

•  Schedule  and  effort  to  tailor  the  organization’s  set  of  standard  processes 

•  Interface  coordination  issue  trends  (i.e.,  number  identified  and  number  closed) 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  integrated  project 
management  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance,  igpus] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai67.elio6] 

•  Establishing,  maintaining,  and  using  the  project’s  defined  process 

•  Coordinating  and  collaborating  with  relevant  stakeholders 

Examples  of  work  products  reviewed  include  the  following:  [pai67.elios] 

•  Project’s  defined  process 

•  Project  plans 

•  Other  plans  that  affect  the  project 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  integrated  project 
management  process  with  higher  level  management  and  resolve 
issues,  [gpii  2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  integrated 
project  management  process,  igpiui 


Elaboration: 

This  generic  practice  is  different  from  the  Establish  the  Project’s 
Defined  Process  specific  practice  in  this  process  area.  This  generic 
practice  establishes  and  maintains  a  defined  integrated  project 
management  process.  The  Establish  the  Project’s  Defined  Process 
specific  practice  defines  the  project’s  defined  process,  which  includes 
all  processes  that  affect  the  project,  [paw.elhs] 
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GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  integrated  project  management  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  17] 


Elaboration: 

This  generic  practice  is  different  from  the  Contribute  to  the 
Organizational  Process  Assets  specific  practice  in  this  process  area. 
This  generic  practice  collects  improvement  information  about  the 
integrated  project  management  processes.  The  Contribute  to  the 
Organizational  Process  Assets  specific  practice  collects  information 
from  processes  in  the  project’s  defined  process.  [pai67.elh9] 


GG  4  Institutionalize  a  Quantitatively  Managed  Process 


The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the  integrated 
project  management  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP118] 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  integrated  project  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives.  [GPiiaj 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  integrated  project 
management  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization.  [GP125] 
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GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  integrated  project  management  process.  [GP1211 
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RISK  MANAGEMENT 

Project  Management 


Purpose 


The  purpose  of  Risk  Management  is  to  identify  potential  problems 
before  they  occur,  so  that  risk-handling  activities  may  be  planned  and 
invoked  as  needed  across  the  life  of  the  product  or  project  to  mitigate 
adverse  impacts  on  achieving  objectives,  [paus] 


Introductory  Notes 


Risk  management  is  a  continuous,  forward-looking  process  that  is  an 
important  part  of  business  and  technical  management  processes.  Risk 
management  should  address  issues  that  could  endanger  achievement 
of  critical  objectives.  A  continuous  risk  management  approach  is 
applied  to  effectively  anticipate  and  mitigate  the  risks  that  have  critical 
impact  on  the  project,  [pa-ms.nioi] 

Effective  risk  management  includes  early  and  aggressive  risk 
identification  through  the  collaboration  and  involvement  of  relevant 
stakeholders,  as  described  in  the  stakeholder  involvement  plan 
addressed  in  the  Project  Planning  process  area.  Strong  leadership 
across  all  relevant  stakeholders  is  needed  to  establish  an  environment 
for  the  free  and  open  disclosure  and  discussion  of  risk.  [pai48.nio2] 

While  technical  issues  are  a  primary  concern  both  early  on  and 
throughout  all  project  phases,  risk  management  must  consider  both 
internal  and  external  sources  for  cost,  schedule,  and  technical  risk. 

Early  and  aggressive  detection  of  risk  is  important  because  it  is  typically 
easier,  less  costly,  and  less  disruptive  to  make  changes  and  correct 
work  efforts  during  the  earlier,  rather  than  the  later,  phases  of  the 

project.  [PA148.N103] 

Risk  management  can  be  divided  into  three  parts:  defining  a  risk 
management  strategy;  identifying  and  analyzing  risks;  and  handling 
identified  risks,  including  the  implementation  of  risk  mitigation  plans 
when  needed.  [pai48.nio4] 
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As  represented  in  the  Project  Planning  and  Project  Monitoring  and 
Control  process  areas,  organizations  may  initially  focus  simply  on  risk 
identification  for  awareness,  and  react  to  the  realization  of  these  risks 
as  they  occur.  The  Risk  Management  process  area  describes  an 
evolution  of  these  specific  practices  to  systematically  plan,  anticipate, 
and  mitigate  risks  to  proactively  minimize  their  impact  on  the  project. 

[PA148.N105] 


Although  the  primary  emphasis  of  the  Risk  Management  process  area 
is  on  the  project,  the  concepts  may  also  be  applied  to  manage 
organizational  risks.  [pai48.nio6] 


Related  Process  Areas 


Refer  to  the  Project  Planning  Process  Area  for  more  information  about 
identification  of  project  risks  and  planning  for  involvement  of  relevant 
stakeholders,  [paus.rioii 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  project  risks.  [paus.rio2] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  to  evaluate 
alternatives  for  selection  and  mitigation  of  identified  risks.  [paub.rio3] 


Specific  Goals 


SG  1  Prepare  for  Risk  Management  [pai48.igioii 


Preparation  for  risk  management  is  conducted. 


SG  2  Identify  and  Analyze  Risks  [pai4s  igio2] 


Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 


SG  3  Mitigate  Risks  [PA148.IG103] 


Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse 
impacts  on  achieving  objectives. 
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Generic  Goals 


GG  1 

Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG2 

Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3 

Institutionalize  a  Defined  Process  [clkm.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4 

Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5 

Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Prepare  for  Risk  Management  [pams .igioij 

SP  1.1-1  Determine  Risk  Sources  and  Categories 

SP  1.2-1  Define  Risk  Parameters 

SP  1 .3-1  Establish  a  Risk  Management  Strategy 

SG  2  Identify  and  Analyze  Risks  [pai48.igio2] 

SP  2.1-1  Identify  Risks 

SP  2.2-1  Evaluate,  Categorize,  and  Prioritize  Risks 

SG  3  Mitigate  Risks  [PA148.IG103] 

SP  3.1-1  Develop  Risk  Mitigation  Plans 
SP  3.2-1  Implement  Risk  Mitigation  Plans 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.glioi] 


GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clim.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioii 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Risk  Management 


Preparation  for  risk  management  is  conducted,  ipaus.igioi] 

Preparation  is  conducted  by  establishing  and  maintaining  a  strategy  for 
identifying,  analyzing,  and  mitigating  risks.  This  is  typically  documented 
in  a  risk  management  plan.  The  risk  management  strategy  addresses 
the  specific  actions  and  management  approach  used  to  apply  and 
control  the  risk  management  program.  This  includes  identifying  the 
sources  of  risk,  the  scheme  used  to  categorize  risks,  and  the 
parameters  used  to  evaluate,  bound,  and  control  risks  for  effective 
handling,  [paus.igioi.nioii 


SP  1.1-1  Determine  Risk  Sources  and  Categories 

Determine  risk  sources  and  categories,  [paus.igioi.spioi] 


Identification  of  risk  sources  provides  a  basis  for  systematically 
examining  changing  situations  overtime  to  uncover  circumstances  that 
impact  the  ability  of  the  project  to  meet  its  objectives.  Risk  sources  are 
both  internal  and  external  to  the  project.  As  the  project  progresses, 
additional  sources  of  risk  may  be  identified.  Establishing  categories  for 
risks  provides  a  mechanism  for  collecting  and  organizing  risks  as  well 
as  ensuring  appropriate  scrutiny  and  management  attention  for  those 
risks  that  can  have  more  serious  consequences  on  meeting  project 

objectives.  [PA148.IG101.SP101.N101] 

Typical  Work  Products 

1.  Risk  source  lists  (external  and  internal)  [paus.igioi.spioi.wioij 

2.  Risk  categories  list  [pau8.igioi.spioi.wio2] 
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Subpractices 

1.  Determine  risk  sources.  [PAi48.iGioi.spioi.subPioi] 

Risk  sources  are  the  fundamental  drivers  that  cause  risks  within  a  project  or 
organization.  There  are  many  sources  of  risks,  both  internal  and  external  to  a 
project.  Risk  sources  identify  common  areas  where  risks  may  originate.  Typical 
internal  and  external  risk  sources  include  the  following:  [PAi48.iGioi.spioi.subPioi.Nioi] 

•  Uncertain  requirements 

•  Unprecedented  efforts— estimates  unavailable 

•  Infeasible  design 

•  Unavailable  technology 

•  Unrealistic  schedule  estimates  or  allocation 

•  Inadequate  staffing  and  skills 

•  Cost  or  funding  issues 

•  Uncertain  or  inadequate  subcontractor  capability 

•  Uncertain  or  inadequate  vendor  capability 

Many  of  these  sources  of  risk  are  often  accepted  without  adequate  planning.  Early 
identification  of  both  internal  and  external  sources  of  risk  can  lead  to  early 
identification  of  risks.  Risk  mitigation  plans  can  then  be  implemented  early  in  the 
project  to  preclude  occurrence  of  the  risks  or  reduce  the  consequences  of  their 
occurrence.  [PAi48.iGi01.sp101.subPi01.Ni02] 

2.  Determine  risk  categories.  [PAi48.iGioi.spioi.sUbPio2] 

Risk  categories  reflect  the  “bins”  for  collecting  and  organizing  risks.  A  reason  for 
identifying  risk  categories  is  to  help  in  the  future  consolidation  of  the  activities  in 
the  risk  mitigation  plans.  [PAi48.iGioi.spioi.subPio2.Nioi] 


The  following  factors  may  be  considered  when  determining  risk  categories: 

[PA148.IG101.SP101.SubP102.N102] 

•  The  phases  of  the  project’s  life-cycle  model  (e.g.,  requirements,  design, 
manufacturing,  test  and  evaluation,  delivery,  disposal) 

•  The  types  of  processes  used 

•  The  types  of  products  used 

•  Program  management  risks  (e.g.,  contract  risks,  budget/cost  risks,  schedule  risks, 
resources  risks,  performance  risks,  supportability  risks) 


A  risk  taxonomy  can  be  used  to  provide  a  framework  for  determining  risk  sources 
and  categories.  [PAi48.iGio1.sp101.subPio2.Nio3] 
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SP  1.2-1  Define  Risk  Parameters 

Define  the  parameters  used  to  analyze  and  categorize  risks,  and 
the  parameters  used  to  control  the  risk  management  effort. 

[PA148.IG101  .SP102] 


Parameters  for  evaluating,  categorizing,  and  prioritizing  risks  include 
the  following:  [pai48.igioi.spio2.nioi] 

•  Risk  likelihood  (i.e.,  probability  of  risk  occurrence) 

•  Risk  consequence  (i.e.,  impact  and  severity  of  risk  occurrence) 

•  Thresholds  to  trigger  management  activities 

Risk  parameters  are  used  to  provide  common  and  consistent  criteria  for 
comparing  the  various  risks  to  be  managed.  Without  these  parameters, 
it  would  be  very  difficult  to  gauge  the  severity  of  the  unwanted  change 
caused  by  the  risk  and  to  prioritize  the  necessary  actions  required  for 
risk  mitigation  planning,  [pai48.igioi.spio2.nio2] 

Typical  Work  Products 

1.  Risk  evaluation,  categorization,  and  prioritization  criteria 

[PA148.IG101.SP102.W101] 

2.  Risk  management  requirements  (control  and  approval  levels, 
reassessment  intervals,  etc.)  ipai48.igioi.spio2.wio2] 

Subpractices 

1 .  Define  consistent  criteria  for  evaluating  and  quantifying  risk 
likelihood  and  severity  levels.  [PAi48.iGioi.spio2.subPioi] 

Consistently  used  criteria  (e.g.,  the  bounds  on  the  likelihood  and  severity  levels) 
allow  the  impacts  of  different  risks  to  be  commonly  understood,  to  receive  the 
appropriate  level  of  scrutiny,  and  to  obtain  the  management  attention  warranted. 

In  managing  dissimilar  risks  (for  example,  personnel  safety  versus  environmental 
pollution),  it  is  important  to  ensure  consistency  in  end  result  (e.g.,  a  high  risk  of 
environmental  pollution  is  as  important  as  a  high  risk  to  personnel  safety). 

[PA148.IG101.SP102.SubP101.N101] 

2.  Define  thresholds  for  each  risk  category.  [PAi48.iGioi.spio2.subPio2] 

For  each  risk  category,  thresholds  can  be  established  to  determine  acceptability 
or  unacceptability  of  risks,  prioritization  of  risks,  or  triggers  for  management 

aCtiOn.  [PA148.IG101.SP102.SubP102.N101] 
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Examples  of  thresholds  include  the  following:  [PAi48.iGi01.sp102.subPi02.Ni02] 

•  Project-wide  thresholds  could  be  established  to  involve  senior  management  when 
product  costs  exceed  10%  of  the  target  cost  or  when  Cost  Performance  Indexes 
(CPIs)  fall  below  0.95. 

•  Schedule  thresholds  could  be  established  to  involve  senior  management  when 
Schedule  Performance  Indexes  (SPIs)  fall  below  0.95. 

•  Performance  thresholds  could  be  set  to  involve  senior  management  when 
specified  key  design  items  (e.g.,  processor  utilization)  exceed  125%  of  the 
intended  design. 


These  may  be  refined  later,  for  each  identified  risk,  to  establish  points  at  which 
more  aggressive  risk  monitoring  is  employed  or  to  signal  the  implementation  of 
risk  mitigation  plans.  [PAi48.iGi01.sp102.subPi02.Ni05] 

3.  Define  bounds  on  the  extent  to  which  thresholds  are  applied 
against  or  within  a  category.  [PAi48.iGioi.spio2.subPio3] 

There  are  few  limits  to  which  risks  can  be  assessed  in  either  a  quantitative  or 
qualitative  fashion.  Definition  of  bounds  (or  boundary  conditions)  can  be  used  to 
help  scope  the  extent  of  the  risk  management  effort  and  avoid  excessive  resource 
expenditures.  Bounds  may  include  exclusion  of  a  risk  source  from  a  category. 
These  bounds  may  also  exclude  any  condition  that  occurs  less  than  a  given 
frequency.  [PAi48.iGio1.sp102.subPio3.Nioi] 


SP  1.3-1  Establish  a  Risk  Management  Strategy 

Establish  and  maintain  the  strategy  to  be  used  for  risk 
management.  [pau8.igioi.spio3] 


A  comprehensive  risk  management  strategy  addresses  items  such  as 

the  following:  [pai48.igioi.spio3.nioi] 

•  The  scope  of  the  risk  management  effort 

•  Methods  and  tools  to  be  used  for  risk  identification,  risk  analysis, 
risk  mitigation,  risk  monitoring,  and  communication 

•  Project-specific  sources  of  risks 

•  How  these  risks  are  to  be  organized,  categorized,  compared,  and 
consolidated 

•  Parameters,  including  likelihood,  consequence,  and  thresholds,  for 
taking  action  on  identified  risks 

•  Risk  mitigation  techniques  to  be  used,  such  as  prototyping, 
simulation,  alternative  designs,  or  evolutionary  development 

•  Definition  of  risk  measures  to  monitor  the  status  of  the  risks 

•  Time  intervals  for  risk  monitoring  or  reassessment 
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The  risk  management  strategy  should  be  guided  by  a  common  vision  of 
success  that  describes  the  desired  future  project  outcomes  in  terms  of 
the  product  that  is  delivered,  its  cost,  and  its  fitness  for  the  task.  The 
risk  management  strategy  is  often  documented  in  an  organizational  or  a 
project  risk  management  plan.  The  risk  management  strategy  is 
reviewed  with  relevant  stakeholders  to  promote  commitment  and 
understanding,  [pai48.igioi.spio3.nio2] 

Typical  Work  Products 

1 .  Project  risk  management  strategy  [pai48.igioi.spio3.wioi] 


SG  2  Identify  and  Analyze  Risks 


Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

[PA148.IG102] 

The  degree  of  risk  impacts  the  resources  assigned  to  handle  an 
identified  risk  and  the  determination  of  when  appropriate  management 
attention  is  required,  [pai48.igio2.nioi] 

Analyzing  risks  entails  identifying  risks  from  the  internal  and  external 
sources  identified  and  then  evaluating  each  identified  risk  to  determine 
its  likelihood  and  consequences.  Categorization  of  the  risk,  based  on  an 
evaluation  against  the  established  risk  categories  and  criteria 
developed  for  the  risk  management  strategy,  provides  the  information 
needed  for  risk  handling.  Related  risks  may  be  grouped  for  efficient 
handling  and  effective  use  of  risk  management  resources,  [pai48.igio2.nio2] 


SP  2.1-1  Identify  Risks 

Identify  and  document  the  risks.  ipai48.igio2.spioi] 


The  identification  of  potential  issues,  hazards,  threats,  and 
vulnerabilities  that  could  negatively  affect  work  efforts  or  plans  is  the 
basis  for  sound  and  successful  risk  management.  Risks  must  be 
identified  and  described  in  an  understandable  way  before  they  can  be 
analyzed  and  managed  properly.  Risks  are  documented  in  a  concise 
statement  that  includes  the  context,  conditions,  and  consequences  of 
risk  occurrence,  [pai48.igio2.spioi.nioi] 
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Risk  identification  should  be  an  organized,  thorough  approach  to  seek 
out  probable  or  realistic  risks  in  achieving  objectives.  To  be  effective, 
risk  identification  should  not  be  an  attempt  to  address  every  possible 
event  regardless  of  how  highly  improbable  it  may  be.  Use  of  the 
categories  and  parameters  developed  in  the  risk  management  strategy, 
along  with  the  identified  sources  of  risk,  can  provide  the  discipline  and 
streamlining  appropriate  to  risk  identification.  The  identified  risks  form  a 
baseline  to  initiate  risk  management  activities.  The  list  of  risks  should 
be  reviewed  periodically  to  reexamine  possible  sources  of  risk  and 
changing  conditions  to  uncover  sources  and  risks  previously  overlooked 
or  nonexistent  when  the  risk  management  strategy  was  last  updated. 

[PA148.IG102.SP101.N102] 


Risk  identification  activities  focus  on  the  identification  of  risks,  not 
placement  of  blame.  The  results  of  risk  identification  activities  are  not 
used  by  management  to  evaluate  the  performance  of  individuals. 

[PA148.IG102.SP101.N104] 


There  are  many  methods  for  identifying  risks.  Typical  identification 

methods  include  the  following:  [pai48.igio2.spioi.nio3] 

•  Examine  each  element  of  the  project  work  breakdown  structure  to 
uncover  risks. 

•  Conduct  a  risk  assessment  using  a  risk  taxonomy. 

•  Interview  subject  matter  experts. 

•  Review  risk  management  efforts  from  similar  products. 

•  Examine  lessons-learned  documents  or  databases. 

•  Examine  design  specifications  and  agreement  requirements. 

Typical  Work  Products 

1.  List  of  identified  risks,  including  the  context,  conditions,  and 
consequences  of  risk  occurrence  [pai48.igio2.spioi.wioi] 

Subpractices 

1 .  Identify  the  risks  associated  with  cost,  schedule,  and  performance 
in  all  appropriate  product  life-cycle  phases.  [PAi48.iGio2.spioi.subPioi] 


280 


Project  Management,  Risk  Management 


CMMI-SW,  vl.1 
Continuous  Representation 


Cost,  schedule,  and  performance  risks  should  be  examined  during  all  phases  of 
the  product  life  cycle  to  the  extent  they  impact  project  objectives.  There  may  be 
potential  risks  discovered  that  are  outside  the  scope  of  the  project’s  objectives  but 
vital  to  customer  interests.  For  example,  the  risks  in  development  costs,  product 
acquisition  costs,  cost  of  spare  (or  replacement)  products,  and  product  disposition 
(or  disposal)  costs  have  design  implications.  The  customer  may  not  have  provided 
requirements  for  the  cost  of  supporting  the  fielded  product.  The  customer  should 
be  informed  of  such  risks,  but  actively  managing  those  risks  may  not  be 
necessary.  The  mechanisms  for  making  such  decisions  should  be  examined  at 
project  and  organization  levels  and  put  in  place  if  deemed  appropriate,  especially 
for  risks  that  impact  the  ability  to  verify  and  validate  the  product. 

[PA148.IG102.SP101.SubP101.N101] 


In  addition  to  the  cost  risks  identified  above,  other  cost  risks  may  include  those 
associated  with  funding  levels,  funding  estimates,  and  distributed  budgets. 

[PA148.IG102.SP101.SubP101.N102] 


Schedule  risks  may  include  risks  associated  with  planned  activities,  key  events, 
and  milestones.  [PAi48.iGio2.sp101.subPio1.Nio3] 

Performance  risks  may  include  risks  associated  with  the  following: 

[PA148.IG102.SP101.SubP101.N104] 

•  Requirements 

•  Analysis  and  design 

•  Application  of  new  technology 

•  Physical  size 

•  Shape 

•  Weight 

•  Manufacturing  and  fabrication 

•  Functional  performance  and  operation 

•  Verification 

•  Validation 

•  Performance  maintenance  attributes 

Performance  maintenance  attributes  are  those  characteristics  that  enable  an  in- 
use  product  to  provide  originally  required  performance,  such  as  maintaining  safety 
and  security  performance.  [PAi48.iGi02.sp101.subPi01.Ni05] 

There  are  other  risks  that  do  not  fall  into  cost,  schedule,  or  performance 

Categories.  [PA148.IG102.SP101.SubP101.N106] 
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Examples  of  these  other  risks  include  the  following:  [PAi48.iGio2.spim.subPioi.Nio7] 

•  Risks  associated  with  strikes 

•  Diminishing  sources  of  supply 

•  Technology  cycle  time 

•  Competition 


2.  Review  environmental  elements  that  may  impact  the  project. 

[PA148.IG102.SP101.SubP102] 

Risks  to  a  project  that  frequently  are  missed  include  those  supposedly  outside  the 
scope  of  the  project  (i.e.,  the  project  does  not  control  whether  they  occur  but  can 
mitigate  their  impact),  such  as  weather,  natural  disasters,  political  changes,  and 
telecommunications  failures.  [PAi48.iGi02.sp101.subPi02.Ni0i] 

3.  Review  all  elements  of  the  work  breakdown  structure  as  part  of 
identifying  risks  to  help  ensure  that  all  aspects  of  the  work  effort 
have  been  considered.  [PAi48.iGio2.spioi.subPio3] 

4.  Review  all  elements  of  the  project  plan  as  part  of  identifying  risks  to 
help  ensure  that  all  aspects  of  the  project  have  been  considered. 

[PA148.IG102.SP101.SubP104] 

Refer  to  the  Project  Planning  process  area  for  more  information 
about  identifying  project  risks.  [PAua.iGi02.sp101.subPi04.Ri0i] 

5.  Document  the  context,  conditions,  and  potential  consequences  of 

the  risk.  [PA148.IG102.SP101.SubP105] 

Risks  statements  are  typically  documented  in  a  standard  format  that  contains  the 
risk  context,  conditions,  and  consequences  of  occurrence.  The  risk  context 
provides  additional  information  such  that  the  intent  of  the  risk  can  be  easily 
understood.  In  documenting  the  context  of  the  risk,  consider  the  relative  time 
frame  of  the  risk,  the  circumstances  or  conditions  surrounding  the  risk  that  has 
brought  about  the  concern,  and  any  doubt  or  uncertainty.  [PAi48.iGi02.sp101.subPi05.Ni0i] 

6.  Identify  the  relevant  stakeholders  associated  with  each  risk. 

[PA148.IG102.SP101.SubP106] 


SP  2.2-1  Evaluate,  Categorize,  and  Prioritize  Risks 

Evaluate  and  categorize  each  identified  risk  using  the  defined  risk 
categories  and  parameters,  and  determine  its  relative  priority. 

[PA1 48.IG102.SP1 02] 
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The  evaluation  of  risks  is  needed  to  assign  relative  importance  to  each 
identified  risk,  and  is  used  in  determining  when  appropriate 
management  attention  is  required.  Often  it  is  useful  to  aggregate  risks 
based  on  their  interrelationships,  and  develop  options  at  an  aggregate 
level.  When  an  aggregate  risk  is  formed  by  a  roll  up  of  lower  level  risks, 
care  must  be  taken  to  ensure  that  important  lower  level  risks  are  not 

ignored.  [PA148.IG102.SP102.N101] 

Collectively,  the  activities  of  risk  evaluation,  categorization,  and 
prioritization  are  sometimes  called  “risk  assessment”  or  “risk  analysis.” 

[PA148.IG102.SP102.N103] 

Typical  Work  Products 

1 .  List  of  risks,  with  a  priority  assigned  to  each  risk  [pai48.igio2.spio2.wioi] 

Subpractices 

1.  Evaluate  the  identified  risks  using  the  defined  risk  parameters. 

[PA148.IG102.SP102.SubP101] 


Each  risk  is  evaluated  and  assigned  values  in  accordance  with  the  defined  risk 
parameters,  which  may  include  likelihood,  consequence  (severity,  or  impact),  and 
thresholds.  The  assigned  risk  parameter  values  can  be  integrated  to  produce 
additional  measures,  such  as  risk  exposure,  which  can  be  used  to  prioritize  risks 
for  handling.  [PAi48.iGi02.sp102.subPi01.Ni0i] 

Often,  a  scale  with  three  to  five  values  is  used  to  evaluate  both  likelihood  and 
consequence.  Likelihood,  for  example,  can  be  categorized  as  remote,  unlikely, 
likely,  highly  likely,  or  a  near  certainty.  [PAi48.iGi02.sp102.subPi01.Ni02] 


Examples  for  consequences  include  the  following:  [PAi48.iGio2.sp102.subPio1.Nio4] 

•  Low 

•  Medium 
.  High 

•  Negligible 

•  Marginal 

•  Significant 

•  Critical 

•  Catastrophic 


Probability  values  are  frequently  used  to  quantify  likelihood.  Consequences  are 
generally  related  to  cost,  schedule,  environmental  impact,  or  human  measures 
(such  as  labor  hours  lost  and  severity  of  injury).  [PAi48.iGi02.sp102.subPi01.Ni05] 
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This  evaluation  is  often  a  difficult  and  time-consuming  task.  Specific  expertise  or 
group  techniques  may  be  needed  to  assess  the  risks  and  gain  confidence  in  the 
prioritization.  In  addition,  priorities  may  require  reevaluation  as  time  progresses. 

[PA148.IG102.SP102.SubP101.N103] 

2.  Categorize  and  group  risks  according  to  the  defined  risk 
categories.  [PAi48.iGio2.spio2.subPio2] 

Risks  are  categorized  into  the  defined  risk  categories,  providing  a  means  to  look 
at  risks  according  to  their  source,  taxonomy,  or  project  component.  Related  or 
equivalent  risks  may  be  grouped  for  efficient  handling.  The  cause-and-effect 
relationships  between  related  risks  are  documented.  [PAi48.iGi02.sp102.subPi02.Ni0i] 

3.  Prioritize  risks  for  mitigation.  [PAi48.iGio2.spio2.subPio3] 

A  relative  priority  is  determined  for  each  risk,  based  on  the  assigned  risk 
parameters.  Clear  criteria  should  be  used  to  determine  the  risk  priority.  The  intent 
of  prioritization  is  to  determine  the  most  effective  areas  to  which  resources  for 
mitigation  of  risks  can  be  applied  with  the  greatest  positive  impact  to  the  project. 

[PA148.IG102.SP102.SubP103.N101] 

SG  3  Mitigate  Risks 


Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse 
impacts  on  achieving  objectives.  [pau8.igio3] 

The  steps  in  handling  risks  include  developing  risk-handling  options, 
monitoring  risks,  and  performing  risk-handling  activities  when  defined 
thresholds  are  exceeded.  Risk  mitigation  plans  are  developed  and 
implemented  for  selected  risks  to  proactively  reduce  the  potential 
impact  of  risk  occurrence.  This  may  also  include  contingency  plans  to 
deal  with  the  impact  of  selected  risks  that  may  occur  despite  attempts  to 
mitigate  them.  The  risk  parameters  used  to  trigger  risk-handling 
activities  are  defined  by  the  risk  management  strategy,  [pai48.igio3.nioi] 


SP  3.1-1  Develop  Risk  Mitigation  Plans 

Develop  a  risk  mitigation  plan  for  the  most  important  risks  to  the 
project,  as  defined  by  the  risk  management  strategy.  [PAua.iGio3.spioi] 
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A  critical  component  of  a  risk  mitigation  plan  is  to  develop  alternative 
courses  of  action,  workarounds,  and  fallback  positions,  with  a 
recommended  course  of  action  for  each  critical  risk.  The  risk  mitigation 
plan  for  a  given  risk  includes  techniques  and  methods  used  to  avoid, 
reduce,  and  control  the  probability  of  occurrence  of  the  risk,  the  extent 
of  damage  incurred  should  the  risk  occur  (sometimes  called  a 
“contingency  plan”),  or  both.  Risks  are  monitored  and  when  they 
exceed  the  established  thresholds,  the  risk  mitigation  plans  are 
deployed  to  return  the  impacted  effort  to  an  acceptable  risk  level.  If  the 
risk  cannot  be  mitigated,  a  contingency  plan  may  be  invoked.  Both  risk 
mitigation  and  contingency  plans  are  often  generated  only  for  selected 
risks  where  the  consequences  of  the  risks  are  determined  to  be  high  or 
unacceptable;  other  risks  may  be  accepted  and  simply  monitored. 

[PA148.IG103.SP101.N102] 


Options  for  handling  risks  typically  include  alternatives  such  as  the 

following:  [PA148.IG103.SP101.N103] 

•  Risk  avoidance:  Changing  or  lowering  requirements  while  still 
meeting  the  user’s  needs 

•  Risk  control:  Taking  active  steps  to  minimize  risks 

•  Risk  transfer:  Reallocating  design  requirements  to  lower  the  risks 

•  Risk  monitoring:  Watching  and  periodically  reevaluating  the  risk  for 
changes  to  the  assigned  risk  parameters 

•  Risk  acceptance:  Acknowledgment  of  risk  but  not  taking  any  action 

Often,  especially  for  high  risks,  more  than  one  approach  to  handling  a 
risk  should  be  generated,  [pai48  igio3.spioi.nio4] 

In  many  cases,  risks  will  be  accepted  or  watched.  Risk  acceptance  is 
usually  done  when  the  risk  is  judged  too  low  for  formal  mitigation,  or 
when  there  appears  to  be  no  viable  way  to  reduce  the  risk.  If  a  risk  is 
accepted,  the  rationale  for  this  decision  should  be  documented.  Risks 
are  watched  when  there  is  an  objectively  defined,  verifiable,  and 
documented  threshold  of  performance,  time,  or  risk  exposure  (the 
combination  of  likelihood  and  consequence)  that  will  trigger  risk 
mitigation  planning  or  invoke  a  contingency  plan  if  it  is  needed. 

[PA148.IG103.SP101.N105] 


Adequate  consideration  should  be  given  early  to  technology 
demonstrations,  models,  simulations,  and  prototypes  as  part  of  risk 
mitigation  planning,  [pai48.igio3.spioi.nio6] 

Typical  Work  Products 

1.  Documented  handling  options  for  each  identified  risk 

[PA148.IG103.SP101.W101] 

2.  Risk  mitigation  plans  [pai48.igio3.spioi.wio2] 
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3.  Contingency  plans  [pai48.igio3.spioi.wio4] 

4.  List  of  those  responsible  for  tracking  and  addressing  each  risk 

[PA148.IG103.SP101.W103] 

Subpractices 

1 .  Determine  the  levels  and  thresholds  that  define  when  a  risk 
becomes  unacceptable  and  triggers  the  execution  of  a  risk 
mitigation  plan  or  a  contingency  plan.  [PAi48.iGio3.spioi.subPioi] 

Risk  level  (derived  using  a  risk  model)  is  a  measure  combining  the  uncertainty  of 
reaching  an  objective  with  the  consequences  of  failing  to  reach  the  objective. 

[PA148.IG103.SP101.SubP101.N101] 

Risk  levels  and  thresholds  that  bound  planned  or  acceptable  performance  must 
be  clearly  understood  and  defined  to  provide  a  means  with  which  risk  can  be 
understood.  Proper  categorization  of  risk  is  essential  for  ensuring  both  appropriate 
priority,  based  on  severity  and  the  associated  management  response.  There  may 
be  multiple  thresholds  employed  to  initiate  varying  levels  of  management 
response.  Typically,  thresholds  for  the  execution  of  risk  mitigation  plans  are  set  to 
engage  before  the  execution  of  contingency  plans.  [PAi48.iGi03.sp101.subPi01.Ni02] 

2.  Identify  the  person  or  group  responsible  for  addressing  each  risk. 

[PA148.IG103.SP101.SubP102] 

3.  Determine  the  cost-to-benefit  ratio  of  implementing  the  risk 
mitigation  plan  for  each  risk.  [PAi48.iGio3.spioi.subPio3j 

Risk  mitigation  activities  should  be  examined  for  the  benefits  they  provide  versus 
the  resources  they  will  expend.  Just  like  any  other  design  activity,  alternative 
plans  may  need  to  be  developed  and  the  costs  and  benefits  of  each  alternative 
are  assessed.  The  most  appropriate  plan  is  then  selected  for  implementation.  At 
times  the  risk  may  be  significant  and  the  benefits  small,  but  the  risk  must  be 
mitigated  to  reduce  the  probability  of  incurring  unacceptable  consequences. 

[PA148.IG103.SP101.SubP103.N101] 

4.  Develop  an  overall  risk  mitigation  plan  for  the  project  to  orchestrate 
the  implementation  of  the  individual  risk  mitigation  and  contingency 

planS.  [PA148.IG103.SP101.SubP104] 

The  complete  set  of  risk  mitigation  plans  may  not  be  affordable.  A  tradeoff 
analysis  should  be  performed  to  prioritize  the  risk  mitigation  plans  for 
implementation.  [PAi48.iGi03.sp101.subPi04.Ni0i] 

5.  Develop  contingency  plans  for  selected  critical  risks  in  the  event 
their  impacts  are  realized.  [PAi48.iGio3.spioi.subPio5] 
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Risk  mitigation  plans  are  developed  and  implemented  as  needed  to  proactively 
reduce  risks  before  they  become  problems.  Despite  best  efforts,  some  risks  may 
be  unavoidable  and  will  become  problems  that  impact  the  project.  Contingency 
plans  can  be  developed  for  critical  risks  to  describe  the  actions  a  project  may  take 
to  deal  with  the  occurrence  of  this  impact.  The  intent  is  to  define  a  proactive  plan 
for  handling  the  risk,  either  to  reduce  the  risk  (mitigation)  or  respond  to  the  risk 
(contingency),  but  in  either  event  to  manage  the  risk.  [PAi48.iGi03.sp101.subPi05.Ni0i] 

Some  risk  management  literature  may  consider  contingency  plans  a  synonym  or 
subset  of  risk  mitigation  plans.  These  plans  also  may  be  addressed  together  as 
risk-handling  or  risk  action  plans.  [PAi48.iGio3.spioi.subPio5.Nio2] 


SP  3.2-1  Implement  Risk  Mitigation  Plans 

Monitor  the  status  of  each  risk  periodically  and  implement  the  risk 
mitigation  plan  as  appropriate.  [pau8.igio3.spio2] 


To  effectively  control  and  manage  risks  during  the  work  effort,  follow  a 
proactive  program  to  regularly  monitor  risks  and  the  status  and  results 
of  risk-handling  actions.  The  risk  management  strategy  defines  the 
intervals  at  which  the  risk  status  should  be  revisited.  This  activity  may 
result  in  the  discovery  of  new  risks  or  new  risk-handling  options  that 
may  require  re-planning  and  reassessment.  In  either  event,  the 
acceptability  thresholds  associated  with  the  risk  should  be  compared 
against  the  status  to  determine  the  need  for  implementing  a  risk 
mitigation  plan,  [pai48.igio3.spio2.nioi] 

Typical  Work  Products 

1 .  Updated  lists  of  risk  status  [pai48.igio3.spio2.wioi] 

2.  Updated  assessments  of  risk  likelihood,  consequence,  and 

thresholds  [PAH8.IG103.SP102.W102] 

3.  Updated  lists  of  risk-handling  options  [pah8.igio3.spio2.wio3] 

4.  Updated  list  of  actions  taken  to  handle  risks  [pah8.igio3.spio2.wio4] 

5.  Risk  mitigation  plans  [pah8.igio3.spio2.wio5] 

Subpractices 

1.  Monitor  risk  status.  [PAH8.iGio3.spio2.subPioi] 

After  a  risk  mitigation  plan  is  initiated,  the  risk  is  still  monitored.  Thresholds  are 
assessed  to  check  for  the  potential  execution  of  a  contingency  plan. 

[PA148.IG103.SP102.SubP101.N101] 

A  periodic  mechanism  for  monitoring  should  be  employed.  [PAi48.iGi03.sp102.subPi01.Ni02] 

2.  Provide  a  method  for  tracking  open  risk-handling  action  items  to 

closure.  [PA148.IG103.SP102.SubP102] 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  action  items.  [PAua.iGi03.sp102.subPi02.Ri0i] 

3.  Invoke  selected  risk-handling  options  when  monitored  risks  exceed 
the  defined  thresholds.  [PAi48.iGio3.spio2.subPio3] 

Quite  often,  risk  handling  is  only  performed  for  those  risks  judged  to  be  “high”  and 
“medium.”  The  risk-handling  strategy  for  a  given  risk  may  include  techniques  and 
methods  to  avoid,  reduce,  and  control  the  likelihood  of  the  risk  or  the  extent  of 
damage  incurred  should  the  risk  (anticipated  event  or  situation)  occur  or  both.  In 
this  context,  risk  handling  includes  both  risk  mitigation  plans  and  contingency 

planS.  [PA148.IG103.SP102.SubP103.N101] 

Risk-handling  techniques  are  developed  to  avoid,  reduce,  and  control  adverse 
impact  to  project  objectives  and  to  bring  about  acceptable  outcomes  in  light  of 
probable  impacts.  Actions  generated  to  handle  a  risk  require  proper  resource 
loading  and  scheduling  within  plans  and  baseline  schedules.  This  re-planning 
effort  needs  to  closely  consider  the  effects  on  adjacent  or  dependent  work 
initiatives  or  activities.  [PAi48.iGi03.sp102.subPi03.Ni02] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  revising  the  project  plan. 

[PA148.IG103.SP102.SubP103.N102.R101] 

4.  Establish  a  schedule  or  period  of  performance  for  each  risk¬ 
handling  activity  that  includes  the  start  date  and  anticipated 
completion  date.  [PAi48.iGio3.spio2.subPio4] 

5.  Provide  continued  commitment  of  resources  for  each  plan  to  allow 
successful  execution  of  the  risk-handling  activities. 

[PA148.IG103.SP102.SubP105] 

6.  Collect  performance  measures  on  the  risk-handling  activities. 

[PA148.IG103.SP102.SubP106] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  risk  management  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area.  [GP102] 
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GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  risk  management  process,  igpws] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  defining  a  risk 
management  strategy  and  identifying,  analyzing,  and  mitigating  risks. 

[PA148.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  risk 
management  process.  [gpio4] 


Elaboration: 

Typically,  this  plan  for  performing  the  risk  management  process  is 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area.  The  plan  for  performing  the  risk 
management  process  differs  from  both  the  risk  management  strategy 
and  the  risk  mitigation  plans  described  in  the  specific  practices  in  this 
process  area.  The  plan  called  for  in  this  generic  practice  would  address 
the  comprehensive  planning  for  all  of  the  specific  practices  in  this 
process  area,  from  determining  risk  sources  and  categories  all  the  way 
through  to  the  implementation  of  risk  mitigation  plans.  In  contrast,  the 
risk  management  strategy  called  for  in  one  specific  practice  would 
address  the  project-specific  risk  strategy  for  things  such  as  risk  sources, 
thresholds,  tools,  and  techniques,  and  would  monitor  time  intervals.  The 
risk  mitigation  plans  called  for  in  another  specific  practice  would 
address  more  focused  items  such  as  the  levels  that  trigger  risk-handling 
activities.  [pah8.elio3] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  risk  management 
process,  developing  the  work  products,  and  providing  the  services 
of  the  process,  [g piosj 
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Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pams.eliob] 

•  Risk  management  databases 

•  Risk  mitigation  tools 

•  Prototyping  tools 

•  Modeling  and  simulation 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
risk  management  process,  igpiob] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  risk  management 
process  as  needed.  igpio7] 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pams.elios] 

•  Risk  management  concepts  and  activities  (e.g.,  risk  identification,  evaluation, 
monitoring,  mitigation) 

•  Measure  selection  for  risk  mitigation 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  risk  management  process 
under  appropriate  levels  of  configuration  management.  /. gpios j 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai48.elhoi 

•  Risk  management  strategy 

•  Identified  risk  items 

•  Risk  mitigation  plans 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  risk 
management  process  as  planned.  [GP1241 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai48.eli20] 

•  Establishing  a  collaborative  environment  for  free  and  open  discussion  of  risk 

•  Reviewing  the  risk  management  strategy  and  risk  mitigation  plans 

•  Participating  in  risk  identification,  analysis,  and  mitigation  activities 

•  Communicating  and  reporting  risk  management  status 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  risk  management  process  against  the  plan 
for  performing  the  process  and  take  appropriate  corrective  action. 

[GP110] 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA148.EL1 13] 

•  Number  of  risks  identified,  managed,  tracked,  and  controlled 

•  Risk  exposure  and  changes  to  the  risk  exposure  for  each  assessed  risk,  and  as  a 
summary  percentage  of  management  reserve 

•  Change  activity  for  the  risk  mitigation  plans  (e.g.,  processes,  schedule,  funding) 

•  Occurrence  of  unanticipated  risks 

•  Risk  categorization  volatility 

•  Comparison  of  estimated  vs.  actual  risk  mitigation  effort  and  impact 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  risk  management  process 
against  its  process  description,  standards,  and  procedures,  and 
address  noncompliance.  [gph3i 
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Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai48.elh6] 

•  Establishing  and  maintaining  a  risk  management  strategy 

•  Identifying  and  analyzing  risks 

•  Mitigating  risks 

Examples  of  work  products  reviewed  include  the  following:  [pai48.elh7] 

•  Risk  management  strategy 

•  Risk  mitigation  plans 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  risk  management 
process  with  higher  level  management  and  resolve  issues.  [GP1121 


Elaboration: 

Reviews  of  the  project  risk  status  are  held  on  a  periodic  and  event- 
driven  basis  with  appropriate  levels  of  management,  to  provide  visibility 
into  the  potential  for  project  risk  exposure  and  appropriate  corrective 
action,  [pams.elhs] 

Typically,  these  reviews  will  include  a  summary  of  the  most  critical  risks, 
key  risk  parameters  (such  as  likelihood  and  consequence  of  these 
risks),  and  the  status  of  risk  mitigation  efforts.  [pam8.elh9] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  risk 
management  process,  [gpiuj 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  risk  management  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[GPU  7] 


292 


Project  Management,  Risk  Management 


CMMI-SW,  vl.1 
Continuous  Representation 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  risk 
management  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP11  8] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  risk  management  process  to  achieve 
the  established  quantitative  quality  and  process-performance 
objectives,  igpusi 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  risk  management  process 
in  fulfilling  the  relevant  business  objectives  of  the  organization. 

[GP12S] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  risk  management  process.  [GP1211 
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QUANTITATIVE  PROJECT  MANAGEMENT 

Project  Management 


Purpose 


The  purpose  of  the  Quantitative  Project  Management  process  area  is  to 
quantitatively  manage  the  project’s  defined  process  to  achieve  the 
project’s  established  quality  and  process-performance  objectives,  [paibs] 


Introductory  Notes 


The  Quantitative  Project  Management  process  area  involves  the 

following:  [pai65.nioi] 

•  Establishing  and  maintaining  the  project’s  quality  and  process- 
performance  objectives 

•  Identifying  suitable  subprocesses  that  compose  the  project’s 
defined  process  based  on  historical  stability  and  capability  data 
found  in  process  performance  baselines  or  models 

•  Selecting  the  subprocesses  of  the  project’s  defined  process  to  be 
statistically  managed 

•  Monitoring  the  project  to  determine  whether  the  project’s  objectives 
for  quality  and  process  performance  are  being  satisfied,  and 
identifying  appropriate  corrective  action 

•  Selecting  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses 

•  Establishing  and  maintaining  an  understanding  of  the  variation  of 
the  selected  subprocesses  using  the  selected  measures  and 
analytic  techniques 

•  Monitoring  the  performance  of  the  selected  subprocesses  to 
determine  whether  they  are  capable  of  satisfying  their  quality  and 
process-performance  objectives,  and  identifying  corrective  action 

•  Recording  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository 
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The  quality  and  process-performance  objectives,  measures,  and 
baselines  identified  above  are  developed  as  described  in  the 
Organizational  Process  Performance  process  area.  Subsequently,  the 
results  of  performing  the  processes  associated  with  the  Quantitative 
Project  Management  process  area  (e.g.,  measurement  definitions  and 
measurement  data)  become  part  of  the  organizational  process  assets 
referred  to  in  the  Organizational  Process  Performance  process  area. 

[PA165.N102] 


To  effectively  address  the  specific  practices  in  this  process  area,  the 
organization  should  have  already  established  a  set  of  standard 
processes  and  related  organizational  process  assets,  such  as  the 
organization’s  measurement  repository  and  the  organization’s  process 
asset  library,  for  use  by  each  project  in  establishing  its  defined  process. 
The  project’s  defined  process  is  a  set  of  subprocesses  that  form  an 
integrated  and  coherent  life  cycle  for  the  project.  It  is  established,  in 
part,  through  selecting  and  tailoring  processes  from  the  organization’s 
set  of  standard  processes.  See  Chapter  3  for  an  explanation  of  how 
“defined  process”  is  used  in  the  CMMI  Product  Suite.  [pai65.nio3] 

Process  performance  is  a  measure  of  the  actual  process  results 
achieved.  Process  performance  is  characterized  by  both  process 
measures  (e.g.,  effort,  cycle  time,  and  defect  removal  efficiency)  and 
product  measures  (e.g.,  reliability,  defect  density,  and  response  time). 

[PA165.N106] 


Subprocesses  are  defined  components  of  a  larger  defined  process.  For 
example,  a  typical  organization's  development  process  may  be  defined 
in  terms  of  subprocesses  such  as  requirements  development,  design, 
build,  test,  and  peer  review.  The  subprocesses  themselves  may  be 
further  decomposed  as  necessary  into  other  subprocesses  and  process 
elements.  [pai65.nio7] 

One  essential  element  of  quantitative  management  is  having 
confidence  in  estimates  (i.e. ,  being  able  to  predict  the  extent  to  which 
the  project  can  fulfill  its  quality  and  process-performance  objectives). 
The  subprocesses  that  will  be  statistically  managed  are  chosen  based 
on  identified  needs  for  predictable  performance.  See  the  definitions  of 
“statistically  managed  process”  and  “quantitatively  managed  process”  in 
Appendix  C,  the  glossary.  See  Chapter  3  for  an  explanation  of  how 
“quality  and  process-performance  objective”  is  used  in  the  CMMI 
Product  Suite.  [PAies.Nios] 

Another  essential  element  of  quantitative  management  is  understanding 
the  nature  and  extent  of  the  variation  experienced  in  process 
performance,  and  recognizing  when  the  project’s  actual  performance 
may  not  be  adequate  to  achieve  the  project’s  quality  and  process- 
performance  objectives.  [PAies.Nioss] 
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Statistical  management  involves  statistical  thinking  and  the  correct  use 
of  a  variety  of  statistical  techniques,  such  as  run  charts,  control  charts, 
confidence  intervals,  prediction  intervals,  and  tests  of  hypotheses. 
Quantitative  management  uses  data  from  statistical  management  to 
help  the  project  predict  whether  it  will  be  able  to  achieve  its  quality  and 
process-performance  objectives  and  identify  what  corrective  action 
should  be  taken,  [paibs.nuo] 

This  process  area  applies  to  managing  a  project,  but  the  concepts 
found  here  also  apply  to  managing  other  groups  and  functions.  Applying 
these  concepts  to  managing  other  groups  and  functions  may  not 
necessarily  contribute  to  achieving  the  organization’s  business 
objectives,  but  may  help  these  groups  and  functions  control  their  own 
processes.  [pai65.nih] 


Examples  of  other  groups  and  functions  include  the  following:  [pai65.nh3] 

•  Quality  assurance 

•  Process  definition  and  improvement 

•  Effort  reporting 

•  Customer  complaint  handling 

•  Problem  tracking  and  reporting 


Related  Process  Areas 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  and  taking 
corrective  action,  [paibs.rioi] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives,  specifying  the 
measures  and  analyses  to  be  performed,  obtaining  and  analyzing 
measures,  and  providing  results.  [pai65.rio2] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 
performance  objectives,  process  performance  analyses,  process 
performance  baselines,  and  process  performance  models.  [pai65.rio3] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organizational  process  assets,  including  the 
organization’s  measurement  repository,  [paws-rwi 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process.  [pai65.rios] 


296 


Project  Management,  Quantitative  Project  Management 


CMMI-SW,  vl.1 
Continuous  Representation 


Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  how  to  identify  the  causes  of  defects  and  other 
problems,  and  taking  action  to  prevent  them  from  occurring  in  the 

future.  [PA165.R106] 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  selecting  and  deploying  improvements  that 
support  the  organization’s  quality  and  process-performance  objectives. 

[PA165.R107] 


Specific  Goals 

SG  1  Quantitatively  Manage  the  Project  [paiss.igioi] 

The  project  is  quantitatively  managed  using  quality  and  process-performance 
objectives. 

SG  2  Statistically  Manage  Subprocess  Performance  [pai65.igio2] 

The  performance  of  selected  subprocesses  within  the  project's  defined 
process  is  statistically  managed. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Gnoi] 

The  process  is  institutionalized  as  an  optimizing  process. 
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Practice-to-Goal  Relationship  Table 


SG  1  Quantitatively  Manage  the  Project  [paiss.igioi] 


SP  1.1-1 

Establish  the  Project’s  Objectives 

SP  1.2-1 

Compose  the  Defined  Process 

SP  1.3-1 

Select  the  Subprocesses  that  Will  Be  Statistically  Managed 

SP  1.4-1 

Manage  Project  Performance 

SG  2  Statistically  Manage  Subprocess  Performance  [pai65.igio2] 

SP  2.1-1 

Select  Measures  and  Analytic  Techniques 

SP  2.2-1 

Apply  Statistical  Methods  to  Understand  Variation 

SP  2.3-1 

Monitor  Performance  of  the  Selected  Subprocesses 

SP  2.4-1 

Record  Statistical  Management  Data 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [clio3.ghoi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clioaglioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliob.glioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Quantitatively  Manage  the  Project 


The  project  is  quantitatively  managed  using  quality  and  process-performance 
objectives,  [paws.igioi] 


SP  1.1-1  Establish  the  Project’s  Objectives 

Establish  and  maintain  the  project’s  quality  and  process- 
performance  Objectives,  [paibs.igioi.spioi] 
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When  establishing  the  project’s  quality  and  process-performance 
objectives,  it  is  often  useful  to  think  ahead  about  which  processes  from 
the  organization’s  set  of  standard  processes  will  be  included  in  the 
project’s  defined  process,  and  what  the  historical  data  indicates 
regarding  their  process  performance.  These  considerations  will  help  in 
establishing  realistic  objectives  for  the  project.  Later,  as  the  project’s 
actual  performance  becomes  known  and  more  predictable,  the 
objectives  may  need  to  be  revised,  [pai65.igioi.spioi.nio2] 

Typical  Work  Products 

1 .  The  project’s  quality  and  process-performance  objectives 

[PA165.IG101.SP101.W101] 

Subpractices 

1 .  Review  the  organization's  objectives  for  quality  and  process 
performance.  [PAi65.iGioi.spioi.subPioi] 

The  intent  of  this  review  is  to  ensure  that  the  project  understands  the  broader 
business  context  in  which  the  project  will  need  to  operate.  The  project’s  objectives 
for  quality  and  process  performance  are  developed  in  the  context  of  these 
overarching  organizational  objectives.  [PAi65.iGioi.spioi.subPioi.Nioi] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  quality  and  process- 

performance  objectives.  [PAie5.IG101.SP101.SubP101.N101.R101] 

2.  Identify  the  quality  and  process  performance  needs  and  priorities  of 
the  customer,  end  users,  and  other  relevant  stakeholders. 

[PA165.iG101.SP101.SubP102] 

Examples  of  quality  and  process  performance  attributes  for  which  needs  and 
priorities  might  be  identified  include  the  following:  [PAi65.iGio1.sp101.subPio2.Nioi] 

•  Functionality 

•  Reliability 

•  Maintainability 

•  Usability 

•  Duration 

•  Predictability 

•  Timeliness 

•  Accuracy 

3.  Identify  how  process  performance  is  to  be  measured. 

[PA165.IG101.SP101.SubP103] 
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Consider  whether  the  measures  established  by  the  organization  are  adequate  for 
assessing  progress  in  fulfilling  customer,  end-user,  and  other  stakeholder  needs 
and  priorities.  It  may  be  necessary  to  supplement  these  with  additional  measures. 

[PA165.IG101  .SP101  .SubP103.N101] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  defining  measures.  [PAi65.iGioi.spioi.subPio3.Nioi.Rioi] 

4.  Define  and  document  measurable  quality  and  process- 
performance  objectives  for  the  project.  [PAi65.iGioi.spioi.subPio4] 

Defining  and  documenting  objectives  for  the  project  involve  the  following: 

[PA165.IG101.SP101.SubP104.N101] 

•  Incorporating  the  organization’s  quality  and  process-performance  objectives 

•  Writing  objectives  that  reflect  the  quality  and  process-performance  needs  and 
priorities  of  the  customer,  end  users,  and  other  stakeholders,  and  the  way  these 
objectives  should  be  measured 

Examples  of  quality  attributes  for  which  objectives  might  be  written  include  the 
following:  [PAi65.iGio1.sp101.subPio4.Nio2] 

•  Mean  time  between  failures 

•  Critical  resource  utilization 

•  Number  and  severity  of  defects  in  the  released  product 

•  Number  and  severity  of  customer  complaints  concerning  the  provided  service 

Examples  of  process  performance  attributes  for  which  objectives  might  be  written 
include  the  following:  [PAi65.iGi01.sp101.subPi04.Ni03] 

•  Percentage  of  defects  removed  by  product  verification  activities  (perhaps  by  type 
of  verification,  such  as  peer  reviews  and  testing) 

•  Defect  escape  rates 

•  Number  and  density  of  defects  (by  severity)  found  during  the  first  year  following 
product  delivery  (or  start  of  service) 

•  Cycle  time 

•  Percentage  of  rework  time 

5.  Derive  interim  objectives  for  each  life-cycle  phase,  as  appropriate, 
to  monitor  progress  toward  achieving  the  project’s  objectives. 

[PA165.IG101.SP101.SubP105] 


An  example  of  a  method  to  predict  future  results  of  a  process  is  the  use  of 
process  performance  models  to  predict  the  latent  defects  in  the  delivered  product 
using  interim  measures  of  defects  identified  during  product  verification  activities 
(e.g.,  peer  reviews  and  testing).  [PAi65.iGio1.sp101.subPio5.Nioi] 
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6.  Resolve  conflicts  among  the  project’s  quality  and  process- 
performance  objectives  (e.g.,  if  one  objective  cannot  be  achieved 
without  compromising  another  objective).  [PAies.iGioi.spioi.subPioe] 

Resolving  conflicts  involves  the  following:  [PAies.iGioi.spioi.subPioe.Nioi] 

•  Setting  relative  priorities  for  the  objectives 

•  Considering  alternative  objectives  in  light  of  long-term  business  strategies  as  well 
as  short-term  needs 

•  Involving  the  customer,  end  users,  senior  management,  project  management,  and 
other  relevant  stakeholders  in  the  tradeoff  decisions 

•  Revising  the  objectives  as  necessary  to  reflect  the  results  of  the  conflict  resolution 

7.  Establish  traceability  to  the  project’s  quality  and  process- 
performance  objectives  from  their  sources,  [paibs.igioi .spioi.subpwj 


Examples  of  sources  for  objectives  include  the  following:  [PAi65.iGi01.sp101.subPi07.Ni0i] 

•  Requirements 

•  Organization's  quality  and  process-performance  objectives 

•  Customer's  quality  and  process-performance  objectives 

•  Business  objectives 

•  Discussions  with  customers  and  potential  customers 

•  Market  surveys 

An  example  of  a  method  to  identify  and  trace  these  needs  and  priorities  is  Quality 
Function  Deployment  (QFD).  [PAi65.iGi01.sp101.subPi07.Ni02] 


8.  Define  and  negotiate  quality  and  process-performance  objectives 

for  suppliers.  [PA165.IG101.SP101.SubP108] 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  establishing  and  maintaining  agreements 

with  suppliers.  pA165.IG101.SP101.SubP108.R101] 

9.  Revise  the  project’s  quality  and  process-performance  objectives  as 
necessary.  [PAi65.iGioi.spioi.subPio9] 


SP  1.2-1  Compose  the  Defined  Process 

Select  the  subprocesses  that  compose  the  project’s  defined 
process  based  on  historical  stability  and  capability  data. 

[PA165.IG101  .SP102] 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  and  maintaining  the  project’s  defined 
process,  pai65.igioi.spio2.rioi] 
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Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  process  asset  library,  which  might 
include  a  process  element  of  known  and  needed  capability. 

[PA16S.IG101.SP102.R102] 


Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  the  organization’s  process  performance 
baselines  and  process  performance  models,  [paib5.igioi.spio2.rio3] 

Subprocesses  are  identified  from  the  process  elements  in  the 
organization's  set  of  standard  processes  and  the  process  artifacts  in  the 
organization's  process  asset  library,  [pai65.igioi.spio2.nioi] 

Typical  Work  Products 

1.  Criteria  used  in  identifying  which  subprocesses  are  valid 
candidates  for  inclusion  in  the  project’s  defined  process 

[PA165.IG101.SP102.W101] 

2.  Candidate  subprocesses  for  inclusion  in  the  project’s  defined 

process  [PA165.IG101.SP102.W102] 

3.  Subprocesses  to  be  included  in  the  project’s  defined  process 

[PA165.IG101.SP102.W103] 

4.  Identified  risks  when  selected  subprocesses  lack  a  process 
performance  history  [pai65.igioi.spio2.wio4] 

Subpractices 

1 .  Establish  the  criteria  to  use  in  identifying  which  subprocesses  are 
valid  candidates  for  use.  [PAi65.iGioi.spio2.subPioi] 

Identification  may  be  based  on  the  following:  [PAi65.iGio1.sp102.subPio1.Nioi] 

•  Quality  and  process-performance  objectives 

•  Existence  of  process-performance  data 

•  Product  line  standards 

•  Project  life-cycle  models 

•  Customer  requirements 

•  Laws  and  regulations 

2.  Determine  whether  the  subprocesses  that  are  to  be  statistically 
managed,  and  that  were  obtained  from  the  organizational  process 
assets,  are  suitable  for  statistical  management.  [PAi65.iGioi.spio2.subPio2] 

A  subprocess  may  be  more  suitable  for  statistical  management  if  it  has  a  history 
of  the  following:  [PAi65.iGi01.sp102.subPi02.Ni0i] 

•  Stable  performance  in  previous  comparable  instances 
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•  Process  performance  data  that  satisfies  the  project's  quality  and  process- 
performance  objectives 

Historical  data  are  primarily  obtained  from  the  organization's  process  performance 
baselines.  However,  these  data  may  not  be  available  for  all  subprocesses. 

[PA165.IG101.SP102.SubP102.N102] 

3.  Analyze  the  interaction  of  subprocesses  to  understand  the 

relationships  among  the  subprocesses  and  the  measured  attributes 
of  the  subprocesses.  [PAi65.iGioi.spio2.subPio3] 


Examples  of  analysis  techniques  include  system  dynamics  models  and 
simulations.  [PAi65.iGio1.sp102.subPio3.Nioi] 


4.  Identify  the  risk  when  no  subprocess  is  available  that  is  known  to 
be  capable  of  satisfying  the  quality  and  process-performance 
objectives  (i.e.,  no  capable  subprocess  is  available  or  the  capability 
of  the  subprocess  is  not  known).  [PAi65.iGioi.spio2.subPio4] 

Even  when  a  subprocess  has  not  been  selected  to  be  statistically  managed, 
historical  data  and  process  performance  models  may  indicate  that  the  subprocess 
is  not  capable  of  satisfying  the  quality  and  process-performance  objectives. 

[PA165.IG101.SP102.SubP104.N101] 


Refer  to  the  Risk  Management  process  area  for  more  information 
about  risk  identification  and  analysis.  [PAi65.iGi01.sp102.subPi04.Ni01.Ri0i] 


SP  1.3-1  Select  the  Subprocesses  that  Will  Be  Statistically  Managed 

Select  the  subprocesses  of  the  project's  defined  process  that  will 
be  statistically  managed,  [pai65.igioi.spw3] 


Selecting  the  subprocesses  to  be  statistically  managed  is  often  a 
concurrent  and  iterative  process  of  identifying  applicable  project  and 
organization  quality  and  process-performance  objectives,  selecting  the 
subprocesses,  and  identifying  the  process  and  product  attributes  to 
measure  and  control.  Often  the  selection  of  a  process,  quality  and 
process-performance  objective,  or  measurable  attribute  will  constrain 
the  selection  of  the  other  two.  For  example,  if  a  particular  process  is 
selected,  the  measurable  attributes  and  quality  and  process- 
performance  objectives  may  be  constrained  by  that  process. 

[PA165.IG101.SP103.N101] 

Typical  Work  Products 

1 .  Quality  and  process-performance  objectives  that  will  be  addressed 
by  statistical  management  [pai65.igioi.spio3.wioi] 

2.  Criteria  used  in  selecting  which  subprocesses  will  be  statistically 

managed  [pai65.igioi.spio3.wio2] 
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3.  Subprocesses  that  will  be  statistically  managed  [pai65.igioi.spio3.wio3] 

4.  Identified  process  and  product  attributes  of  the  selected 
subprocesses  that  should  be  measured  and  controlled 

[PA165.IG101.SP103.W104] 

Subpractices 

1 .  Identify  which  of  the  quality  and  process-performance  objectives  of 
the  project  will  be  statistically  managed.  [PAi65.iGioi.spio3.subPioi] 

2.  Identify  the  criteria  to  be  used  in  selecting  the  subprocesses  that 
are  the  main  contributors  to  achieving  the  identified  quality  and 
process-performance  objectives  and  for  which  predictable 
performance  is  important.  [PAi65.iGioi.spio3.subPio2] 

Examples  of  sources  for  criteria  used  in  selecting  subprocesses  include  the 
following:  [PAi65.iGi01.sp103.subPi02.Ni02] 

•  Customer  requirements  related  to  quality  and  process  performance 

•  Quality  and  process-performance  objectives  established  by  the  customer 

•  Quality  and  process-performance  objectives  established  by  the  organization 

•  Organization’s  performance  baselines  and  models 

•  Stable  performance  of  the  subprocess  on  other  projects 

•  Laws  and  regulations 

3.  Select  the  subprocesses  that  will  be  statistically  managed  using  the 
selection  criteria.  [PAi65.iGioi.spio3.subPio4] 

It  may  not  be  possible  to  statistically  manage  some  subprocesses  (e.g.,  where 
new  subprocesses  and  technologies  are  being  piloted).  In  other  cases,  it  may  not 
be  economically  justifiable  to  apply  statistical  techniques  to  certain  subprocesses. 

[PA165.IG101.SP103.SubP104.N101] 

4.  Identify  the  product  and  process  attributes  of  the  selected 
subprocesses  that  will  be  measured  and  controlled. 

[PA165.IG101.SP103.SubP103] 


Examples  of  product  and  process  attributes  include  the  following: 

[PA165.IG101.SP103.SubP103.N101] 

•  Defect  density 

•  Cycle  time 

•  Test  coverage 
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SP  1.4-1  Manage  Project  Performance 

Monitor  the  project  to  determine  whether  the  project’s  objectives 
for  quality  and  process  performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate,  [pai65.igwi.spw4] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 

information  about  analyzing  and  using  measures,  [pai65.igioi.spio4.rwi] 

A  prerequisite  for  such  a  comparison  is  that  the  selected  subprocesses 

of  the  project’s  defined  process  are  being  statistically  managed  and 

their  process  capability  is  understood,  [pai65.igioi.spio4.nioi] 

Typical  Work  Products 

1 .  Estimates  (predictions)  of  the  achievement  of  the  project’s  quality 
and  process-performance  objectives  [pai65.igioi.spio4.wioi] 

2.  Documentation  of  the  risks  in  achieving  the  project’s  quality  and 
process-performance  objectives  [pai65.igioi.spio4.wio2] 

3.  Documentation  of  actions  needed  to  address  the  deficiencies  in 
achieving  the  project’s  objectives  [pai65.igioi.spio4.wio3] 

Subpractices 

1 .  Periodically  review  the  performance  of  each  subprocess  and  the 
capability  of  each  subprocess  selected  to  be  statistically  managed, 
to  appraise  progress  toward  achieving  the  project’s  quality  and 
process-performance  objectives.  [PAies.icioi.spm.subPioi] 

The  process  capability  of  each  selected  subprocess  is  determined  with  respect  to 
that  subprocess’  established  quality  and  process-performance  objectives.  These 
objectives  are  derived  from  the  project’s  quality  and  process-performance 
objectives,  which  are  for  the  project  as  a  whole.  [PAi65.iGioi.spio4.subPioi.Nioi] 

2.  Periodically  review  the  actual  results  achieved  against  the 
established  interim  objectives  for  each  phase  of  the  project  life 
cycle  to  appraise  progress  toward  achieving  the  project’s  quality 
and  process-performance  objectives.  [PAi65.iGioi.spio4.subPio2] 

3.  Track  suppliers'  results  for  achieving  their  quality  and  process- 

performance  objectives.  [PA165.IG101.SP104.SubP103] 

4.  Use  process  performance  models  calibrated  with  obtained 
measures  of  critical  attributes  to  estimate  progress  toward 
achieving  the  project’s  quality  and  process-performance  objectives. 
Process  performance  models  are  used  to  estimate  progress  toward 
achieving  objectives  that  cannot  be  measured  until  a  future  phase 
in  the  project  life  cycle.  An  example  is  the  use  of  process 
performance  models  to  predict  the  latent  defects  in  the  delivered 
product  using  interim  measures  of  defects  identified  during  peer 
reviews.  [PAi65.iGioi.spio4.subPio4] 
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Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  process  performance  models. 

[PA165.IG101.SP104.SubP104.R101] 


The  calibration  is  based  on  the  results  obtained  from  performing  the  previous 

subpractices.  [PA165.IG101.SP104.SubP104.N101] 

5.  Identify  and  manage  the  risks  associated  with  achieving  the 
project’s  quality  and  process-performance  objectives. 

[PA1 65.IG1 01  .SP1 04.SubP1 05] 


Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks.  [PAi65.iGioi.spio4.subPio5.Rioi] 

Example  sources  of  the  risks  include  the  following:  [PAi65.iGio1.sp104.subPio5.Nioi] 

•  Inadequate  stability  and  capability  data  in  the  organization’s  measurement 
repository 

•  Subprocesses  having  inadequate  performance  or  capability 

•  Suppliers  not  achieving  their  quality  and  process-performance  objectives 

•  Lack  of  visibility  into  supplier  capability 

•  Inaccuracies  in  the  organization’s  process  performance  models  for  predicting 
future  performance 

•  Deficiencies  in  predicted  process  performance  (estimated  progress) 

•  Other  identified  risks  associated  with  identified  deficiencies 


6.  Determine  and  document  actions  needed  to  address  the 
deficiencies  in  achieving  the  project’s  quality  and  process- 

performance  objectives.  [PA165.IG101.SP104.SubP106] 

The  intent  of  these  actions  is  to  plan  and  deploy  the  right  set  of  activities, 
resources,  and  schedule  to  place  the  project  back  on  track  as  much  as  possible  to 
meet  its  objectives.  [PAi65.iGi01.sp104.subPi06.Ni0i] 


Examples  of  actions  that  can  be  taken  to  address  deficiencies  in  achieving  the 

project’s  objectives  include  the  following:  [PAi65.iGi01.sp104.subPi06.Ni02] 

•  Changing  quality  or  process  performance  objectives  so  that  they  are  within  the 
expected  range  of  the  project’s  defined  process 

•  Improving  the  implementation  of  the  project’s  defined  process  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  project’s  performance  within 
the  objectives  without  having  to  move  the  mean) 

•  Adopting  new  subprocesses  and  technologies  that  have  the  potential  for  satisfying 
the  objectives  and  managing  the  associated  risks 

•  Identifying  the  risk  and  risk  mitigation  strategies  for  the  deficiencies 

•  Terminating  the  project 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

[PA165.IG101.SP104.SubP106.N102.R101] 


SG  2  Statistically  Manage  Subprocess  Performance 


The  performance  of  selected  subprocesses  within  the  project's  defined 
process  is  statistically  managed.  [paw5.igio2] 

This  specific  goal  describes  an  activity  critical  to  achieving  the 
Quantitatively  Manage  the  Project  specific  goal  of  this  process  area. 
The  specific  practices  under  this  specific  goal  describe  how  to 
statistically  manage  the  subprocesses  whose  selection  was  described 
in  the  specific  practices  under  the  first  specific  goal.  When  the  selected 
subprocesses  are  statistically  managed,  their  capability  to  achieve  their 
objectives  can  be  determined.  By  these  means,  it  will  be  possible  to 
predict  whether  the  project  will  be  able  to  achieve  its  objectives,  which 
is  key  to  quantitatively  managing  the  project,  [pai65.igio2.nioi] 


SP  2.1-1  Select  Measures  and  Analytic  Techniques 

Select  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses,  [pai65.igio2.spwi] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  measurable  objectives;  on  defining, 
collecting,  and  analyzing  measures ;  and  on  revising  measures  and 
statistical  analysis  techniques,  [pai65.igio2.spioi.rwi] 

Typical  Work  Products 

1 .  Definitions  of  the  measures  and  analytic  techniques  to  be  used  in 
(or  proposed  for)  statistically  managing  the  subprocesses 

[PA165.IG102.SP101.W101] 

2.  Operational  definitions  of  the  measures,  their  collection  points  in 
the  subprocesses,  and  how  the  integrity  of  the  measures  will  be 
determined  [pai6s.igio2.spioi.wio2] 

3.  Traceability  of  measures  back  to  the  project’s  quality  and  process- 

performance  objectives  [PA16S.IG102.SP101.W103] 

4.  Instrumented  organizational  support  environment  to  support 
automatic  data  collection  [pai65.igio2.spioi.wio4] 

Subpractices 

1 .  Identify  common  measures  from  the  organizational  process  assets 
that  support  statistical  management.  [PAi6s.iGio2.spioi.subPioi] 
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Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  common  measures.  [PAi6s.iGi02.sp101.subPi01.Ri0i] 

Product  lines  or  other  stratification  criteria  may  categorize  common  measures. 

[PA165.IG102.SP101.SubP101.N101] 

2.  Identify  additional  measures  that  may  be  needed  for  this  instance 
to  cover  critical  product  and  process  attributes  of  the  selected 

SUbprOCeSSeS.  [PA165.IG102.SP101.SubP102] 

In  some  cases,  measures  may  be  research  oriented.  Such  measures  should  be 
explicitly  identified.  [PAi65.iGi02.sp101.subPi02.Ni02] 

3.  Identify  the  measures  that  are  appropriate  for  statistical 
management.  [PAi65.iGio2.spioi.subPio3] 

Critical  criteria  for  selecting  statistical  management  measures  include  the 
following:  [PAi65.iGio2.sp101.subPio3.Nioi] 

•  Controllable  (e.g.,  can  a  measure’s  values  be  changed  by  changing  how  the 
subprocess  is  implemented?) 

•  Adequate  performance  indicator  (e.g.,  is  the  measure  a  good  indicator  of  how  well 
the  subprocess  is  performing  relative  to  the  objectives  of  interest?) 

Examples  of  subprocess  measures  include  the  following:  [PAi65.iGio2.sp101.subPi03.Ni02] 

•  Requirements  volatility 

•  Ratios  of  estimated  to  measured  values  of  the  planning  parameters  (e.g.,  size, 
cost,  and  schedule) 

•  Coverage  and  efficiency  of  peer  reviews 

•  Test  coverage  and  efficiency 

•  Effectiveness  of  training  (e.g.,  percent  of  planned  training  completed  and  test 
scores) 

•  Reliability 

•  Percentage  of  the  total  defects  inserted  or  found  in  the  different  phases  of  the 
project  life  cycle 

•  Percentage  of  the  total  effort  expended  in  the  different  phases  of  the  project  life 
cycle 


4.  Specify  the  operational  definitions  of  the  measures,  their  collection 
points  in  the  subprocesses,  and  how  the  integrity  of  the  measures 
will  be  determined.  [PAi65.iGio2.spioi.subPio4] 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows:  [PAie5.iGi02.sp101.subPi04.Ni0i] 

•  Communication:  What  has  been  measured,  how  it  was  measured,  what  the  units 
of  measure  are,  and  what  has  been  included  or  excluded 
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•  Repeatability:  Whether  the  measurement  can  be  repeated,  given  the  same 
definition,  to  get  the  same  results 

5.  Analyze  the  relationship  of  the  identified  measures  to  the 
organization’s  and  project’s  objectives,  and  derive  objectives  that 
state  specific  target  measures  or  ranges  to  be  met  for  each 
measured  attribute  of  each  selected  subprocess. 

[PA1 65.IG1 02.SP1 01  .SubPI  05] 

6.  Instrument  the  organizational  support  environment  to  support 
collection,  derivation,  and  analysis  of  statistical  measures. 

[PA1 65.IG1 02.SP1 01  .SubPI  06] 

The  instrumentation  is  based  on  the  following:  [PAie5.iGi02.sp101.subPi06.Ni0i] 

•  Description  of  the  organization's  set  of  standard  processes 

•  Description  of  the  project’s  defined  process 

•  Capabilities  of  the  organizational  support  environment 

7.  Identify  the  appropriate  statistical  analysis  techniques  that  are 
expected  to  be  useful  in  statistically  managing  the  selected 

SUbprOCeSSeS.  [PA165.IG102.SP101.SubP107] 

The  concept  of  “one  size  does  not  fit  all”  applies  to  statistical  analysis  techniques. 
What  makes  a  particular  technique  appropriate  is  not  just  the  type  of  measures, 
but  more  importantly,  how  the  measures  will  be  used  and  whether  the  situation 
warrants  applying  that  technique.  The  appropriateness  of  the  selection  may  need 
to  be  investigated  from  time  to  time.  [PAi65.iGi02.sp101.subPi07.Ni0i] 

Examples  of  statistical  analysis  techniques  are  given  in  the  next  specific  practice. 

[PA165.IG102.SP101.SubP107.N102] 

8.  Revise  the  measures  and  statistical  analysis  techniques  as 
necessary,  [pai65.igio2.spi 01  .subPi osi 


SP  2.2-1  Apply  Statistical  Methods  to  Understand  Variation 

Establish  and  maintain  an  understanding  of  the  variation  of  the 
selected  subprocesses  using  the  selected  measures  and  analytic 
techniques.  [PAi6s.iGi02.spw2] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  collecting,  analyzing,  and  using  measure  results. 

[pai6s.igio2.spio2.rioi] 


Understanding  variation  is  achieved,  in  part,  by  collecting  and  analyzing 
process  and  product  measures  so  that  special  causes  of  variation  can 
be  identified  and  addressed  to  achieve  predictable  performance. 

[PA165.IG102.SP102.N101] 
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A  special  cause  of  process  variation  is  characterized  by  an  unexpected 
change  in  process  performance.  Special  causes  are  also  known  as 
“assignable  causes”  because  they  can  be  identified,  analyzed,  and 
addressed  to  prevent  recurrence.  [PAi65.iGi02.sp102.Ni02] 

The  identification  of  special  causes  of  variation  is  based  on  departures 
from  the  system  of  common  causes  of  variation.  These  departures  can 
be  identified  by  the  presence  of  extreme  values,  or  other  identifiable 
patterns  in  the  data  collected  from  the  subprocess  or  associated  work 
products.  Knowledge  of  variation  and  insight  about  potential  sources  of 
anomalous  patterns  are  typically  needed  to  detect  special  causes  of 

variation.  [PAI65.IGi02.SPi02.Ni03] 


Sources  of  anomalous  patterns  of  variation  may  include  the  following:  [pai65.igio2.spio2.nio4] 

•  Lack  of  process  compliance 

•  Undistinguished  influences  of  multiple  underlying  subprocesses  on  the  data 

•  Ordering  or  timing  of  activities  within  the  subprocess 

•  Uncontrolled  inputs  to  the  subprocess 

•  Environmental  changes  during  subprocess  execution 

•  Schedule  pressure 

•  Inappropriate  sampling  or  grouping  of  data 


Typical  Work  Products 

1 .  Collected  measures  [pai65.igio2.spio2.wioi] 

2.  Natural  bounds  of  process  performance  for  each  measured 
attribute  of  each  selected  subprocess  [PAi65.iGi02.sp102.w102] 

3.  Process  performance  compared  to  the  natural  bounds  of  process 
performance  for  each  measured  attribute  of  each  selected 
subprocess  [PAI65.IGi02.SPi02.Wi03] 

Subpractices 

1 .  Establish  trial  natural  bounds  for  subprocesses  having  suitable 
historical  performance  data.  [PAi65.iGio2.spio2.subPioi] 

Refer  to  the  Organizational  Process  Performance  process  area  for 
more  information  about  organizational  process  performance 
baselines.  [PAi65.iGio2.spw2.subPio1.Rioi] 

Natural  bounds  of  an  attribute  are  the  range  within  which  variation  normally 
occurs.  All  processes  will  show  some  variation  in  process  and  product  measures 
each  time  they  are  executed.  The  issue  is  whether  this  variation  is  due  to  common 
causes  of  variation  in  the  normal  performance  of  the  process  or  to  some  special 
cause  that  can  and  should  be  identified  and  removed.  [PAi65.iGio2.sp102.subPio1.Nioi] 
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When  a  subprocess  is  initially  executed,  suitable  data  for  establishing  trial  natural 
bounds  are  sometimes  available  from  prior  instances  of  the  subprocess  or 
comparable  subprocesses,  process  performance  baselines,  or  process 
performance  models.  These  data  are  typically  contained  in  the  organization’s 
measurement  repository.  As  the  subprocess  is  executed,  data  specific  to  that 
instance  are  collected  and  used  to  update  and  replace  the  trial  natural  bounds. 
However,  if  the  subprocess  in  question  has  been  materially  tailored,  or  if  the 
conditions  are  materially  different  than  in  previous  instantiations,  the  data  in  the 
repository  may  not  be  relevant  and  should  not  be  used.  [PAi65.iGi02.sp102.subPi01.Ni02] 

In  some  cases,  there  may  be  no  historical  comparable  data  (for  example,  when 
introducing  a  new  subprocess,  when  entering  a  new  application  domain,  or  when 
significant  changes  have  been  made  to  the  subprocess).  In  such  cases,  trial 
natural  bounds  will  have  to  be  made  from  early  process  data  of  this  subprocess. 
These  trial  natural  bounds  must  then  be  refined  and  updated  as  subprocess 
execution  continues.  [PAi65.iGi02.sp102.subPi01.Ni03] 


Examples  of  criteria  for  determining  whether  data  are  comparable  include  the 
following:  [PAi65.iGi02.sp102.subPi01.Ni04] 

•  Product  lines 

•  Application  domain 

•  Work  product  and  task  attributes  (e.g.,  size  of  product) 

•  Size  of  project 


2.  Collect  data,  as  defined  by  the  selected  measures,  on  the 
subprocesses  as  they  execute.  [PAi65.iGio2.spio2.subPio2] 

3.  Calculate  the  natural  bounds  of  process  performance  for  each 
measured  attribute.  [PAi65.iGio2.spio2.subPio3] 


Examples  of  where  the  natural  bounds  are  calculated  include  the  following: 

[PA165.IG102.SP102.SubP103.N101] 

•  Control  charts 

•  Confidence  intervals  (for  parameters  of  distributions) 

•  Prediction  intervals  (for  future  outcomes) 

4.  Identify  special  causes  of  variation.  [PAi65.iGio2.spio2.subPio4] 


An  example  of  a  criterion  for  detecting  a  special  cause  of  process  variation  in  a 
control  chart  is  a  data  point  that  falls  outside  of  the  3-sigma  control  limits. 

[PA165.IG102.SP102.SubP104.N101] 


The  criteria  for  detecting  special  causes  of  variation  are  based  on  statistical  theory 
and  experience  and  depend  on  economic  justification.  As  criteria  are  added, 
special  causes  are  more  likely  to  be  identified  if  present,  but  the  likelihood  of  false 
alarms  also  increases.  [PAi65.iGi02.sp102.subPi04.Ni02] 
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5.  Analyze  the  special  cause  of  process  variation  to  determine  the 
reasons  the  anomaly  occurred.  [PAi65.iGio2.spio2.subPio5] 


Examples  of  techniques  for  analyzing  the  reasons  for  special  causes  of  variation 
include  the  following:  [PAi65.iGi02.sp102.subPi05.Ni0i] 

•  Cause-and-effect  (fishbone)  diagrams 

•  Designed  experiments 

•  Control  charts  (applied  to  subprocess  inputs  or  to  lower  level  subprocesses) 

•  Subgrouping  (analyzing  the  same  data  segregated  into  smaller  groups  based  on 
an  understanding  of  how  the  subprocess  was  implemented  facilitates  isolation  of 
special  causes) 


Some  anomalies  may  simply  be  extremes  of  the  underlying  distribution  rather 
than  problems.  The  people  implementing  a  subprocess  are  usually  the  ones  best 
able  to  analyze  and  understand  special  causes  of  variation.  [PAi65.iGio2.sp102.subPio5.Nio2] 

6.  Determine  what  corrective  action  should  be  taken  when  special 
causes  of  variation  are  identified.  [PAi65.iGio2.spio2.subPio6] 

Removing  a  special  cause  of  process  variation  does  not  change  the  underlying 
subprocess.  It  addresses  an  error  in  the  way  the  subprocess  is  being  executed. 

[PA165.IG102.SP102.SubP106.N101] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

[PA165.IG102.SP102.SubP106.N101.R101] 

7.  Recalculate  the  natural  bounds  for  each  measured  attribute  of  the 
selected  subprocesses  as  necessary.  [PAi65.iGio2.spio2.subPio7] 

Recalculating  the  (statistically  estimated)  natural  bounds  is  based  on  measured 
values  that  signify  that  the  subprocess  has  changed,  not  on  expectations  or 
arbitrary  decisions.  [PAi65.iGi02.sp102.subPi07.Ni0i] 


Examples  of  when  the  natural  bounds  may  need  to  be  recalculated  include  the 
following:  [PAi65.iGi02.sp102.subPi07.Ni02] 

•  There  are  incremental  improvements  to  the  subprocess 

•  New  tools  are  deployed  for  the  subprocess 

•  A  new  subprocess  is  deployed 

•  The  collected  measures  suggest  that  the  subprocess  mean  has  permanently 
shifted  or  the  subprocess  variation  has  permanently  changed 
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SP  2.3-1  Monitor  Performance  of  the  Selected  Subprocesses 

Monitor  the  performance  of  the  selected  subprocesses  to 
determine  their  capability  to  satisfy  their  quality  and  process- 
performance  objectives,  and  identify  corrective  action  as 
necessary.  [pai65.igio2.spio3] 


The  intent  of  this  specific  practice  is  to  do  the  following:  [pai65.igio2.spio3.nioi] 

•  Determine  statistically  the  process  behavior  expected  from  the 
subprocess 

•  Appraise  the  probability  that  the  process  will  meet  its  quality  and 
process-performance  objectives 

•  Identify  the  corrective  action  to  be  taken,  based  upon  a  statistical 
analysis  of  the  process  performance  data 

Corrective  action  may  include  renegotiating  the  affected  project 
objectives,  identifying  and  implementing  alternative  subprocesses,  or 
identifying  and  measuring  lower  level  subprocesses  to  achieve  greater 
detail  in  the  performance  data.  Any  or  all  of  these  actions  are  intended 
to  help  the  project  use  a  more  capable  process.  See  the  definition  of 
“capable  process”  in  Appendix  C,  the  glossary,  [pai65.igio2.spio3.nio2] 

A  prerequisite  for  comparing  the  capability  of  a  selected  subprocess 
against  its  quality  and  process-performance  objectives  is  that  the 
performance  of  the  subprocess  is  stable  and  predictable  with  respect  to 
its  measured  attributes,  [pai65.igio2.spio3.nio4] 

Process  capability  is  analyzed  for  those  subprocesses  and  those 
measured  attributes  for  which  (derived)  objectives  have  been 
established.  Not  all  subprocesses  or  measured  attributes  that  are 
statistically  managed  are  analyzed  regarding  process  capability. 

[PA165.IG102.SP103.N105] 


The  historical  data  may  be  inadequate  for  initially  determining  whether 
the  subprocess  is  capable.  It  also  is  possible  that  the  estimated  natural 
bounds  for  subprocess  performance  may  shift  away  from  the  quality 
and  process-performance  objectives.  In  either  case,  statistical  control 
implies  monitoring  capability  as  well  as  stability,  [pai65.igio2.spio3.nio6] 

Typical  Work  Products 

1 .  Natural  bounds  of  process  performance  for  each  selected 
subprocess  compared  to  its  established  (derived)  objectives 

[PA165.IG102.SP103.W101] 

2.  For  each  subprocess,  its  process  capability  [PAi65.iGi02.sp103.w102] 

3.  For  each  subprocess,  the  actions  needed  to  address  deficiencies 
in  its  process  capability  [pai65.igio2.spio3.wio3] 


Project  Management,  Quantitative  Project  Management 


313 


CMMI-SW,  vl.1 
Continuous  Representation 

Subpractices 

1 .  Compare  the  quality  and  process-performance  objectives  to  the 
natural  bounds  of  the  measured  attribute.  [PAi65.iGio2.spio3.subPioi] 

This  comparison  provides  an  appraisal  of  the  process  capability  for  each 
measured  attribute  of  a  subprocess.  These  comparisons  can  be  displayed 
graphically,  in  ways  that  relate  the  estimated  natural  bounds  to  the  objectives  or 
as  process  capability  indices,  which  summarize  the  relationship  of  the  objectives 
to  the  natural  bounds.  [PAi65.iGi02.sp103.subPi01.Ni0i] 

2.  Monitor  changes  in  quality  and  process-performance  objectives 
and  selected  subprocess’  process  capability.  [PAi65.iGio2.spio3.subPio2] 

3.  Identify  and  document  subprocess  capability  deficiencies. 

[PA165.IG102.SP103.SubP103] 

4.  Determine  and  document  actions  needed  to  address  subprocess 
capability  deficiencies.  [PAi65.iGio2.spio3.subPio4] 


Examples  of  actions  that  can  be  taken  when  a  selected  subprocess’  performance 

does  not  satisfy  its  objectives  include  the  following:  [PAi65.iGi02.sp103.subPi04.Ni0i] 

•  Changing  quality  and  process-performance  objectives  so  that  they  are  within  the 
subprocess’  process  capability 

•  Improving  the  implementation  of  the  existing  subprocess  so  as  to  reduce  its 
normal  variability  (reducing  variability  may  bring  the  natural  bounds  within  the 
objectives  without  having  to  move  the  mean) 

•  Adopting  new  process  elements  and  subprocesses  and  technologies  that  have 
the  potential  for  satisfying  the  objectives  and  managing  the  associated  risks 

•  Identifying  risks  and  risk  mitigation  strategies  for  each  subprocess’  process 
capability  deficiency 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action. 

[PA16S.IG102.SP103.SubP104.N101.R101] 


SP  2.4-1  Record  Statistical  Management  Data 

Record  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository,  [pai65.igio2.spi 04] 


Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  managing  and  storing  data,  measurement  definitions, 

and  reSUltS.  [PA16S.IG102.SP104.R101] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  the  organization’s  measurement  repository. 

[PA16S.IG102.SP104.R102] 
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Typical  Work  Products 

1 .  Statistical  and  quality  management  data  recorded  in  the 
organization’s  measurement  repository  [pai65.igio2.spio4.wioi] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  quantitative  project  management 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  quantitative  project  management  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  quantitatively 
managing  the  project  using  quality  and  process-performance  objectives, 
and  statistically  managing  selected  subprocesses  within  the  project’s 
defined  process  [pai65.elioij 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  quantitative 
project  management  process.  [gpio4} 


Elaboration: 

Typically,  this  plan  for  performing  the  quantitative  project  management 
process  is  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area,  [paibselih] 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  quantitative  project 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpiosj 


Elaboration: 

Special  expertise  in  statistics  and  statistical  process  control  may  be 
needed  to  define  the  techniques  for  statistical  management  of  selected 
subprocesses,  but  staff  will  use  the  tools  and  techniques  to  perform  the 
statistical  management.  Special  expertise  in  statistics  may  also  be 
needed  for  analyzing  and  interpreting  the  measures  resulting  from 
statistical  management.  [pai65.elio2] 


Examples  of  other  resources  provided  include  the  following  tools:  [pai65.eho3] 

•  System  dynamics  models 

•  Automated  test-coverage  analyzers 

•  Statistical  process  and  quality  control  packages 

•  Statistical  analysis  packages 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
quantitative  project  management  process,  [gpiobj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  quantitative  project 
management  process  as  needed,  [g pio7i 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pai65.elio4] 

•  Process  modeling  and  analysis 

•  Process  measurement  data  selection,  definition,  and  collection 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  quantitative  project 
management  process  under  appropriate  levels  of  configuration 
management,  [g piosi 
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Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai65.elho] 

•  Subprocesses  to  be  included  in  the  project’s  defined  process 

•  Operational  definitions  of  the  measures,  their  collection  points  in  the 
subprocesses,  and  how  the  integrity  of  the  measures  will  be  determined 

•  Collected  measures 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  quantitative 
project  management  process  as  planned.  igpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai65.elio9] 

•  Establishing  project  objectives 

•  Resolving  issues  among  the  project’s  quality  and  process-performance  objectives 

•  Appraising  performance  of  the  selected  subprocesses 

•  Identifying  and  managing  the  risks  in  achieving  the  project’s  quality  and  process- 
performance  objectives 

•  Identifying  what  corrective  action  should  be  taken 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  quantitative  project  management  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuo] 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA165.EL105] 

•  Profile  of  subprocesses  under  statistical  management  (e.g.,  number  planned  to  be 
under  statistical  management,  number  currently  being  statistically  managed,  and 
number  that  are  statistically  stable) 

•  Number  of  special  causes  of  variation  identified 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  quantitative  project 
management  process  against  its  process  description,  standards, 
and  procedures,  and  address  noncompliance.  igph3i 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai65.eho6] 

•  Quantitatively  managing  the  project  using  quality  and  process-performance 
objectives 

•  Statistically  managing  selected  subprocesses  within  the  project’s  defined  process 

Examples  of  work  products  reviewed  include  the  following:  [paibs.elios] 

•  Subprocesses  to  be  included  in  the  project’s  defined  process 

•  Operational  definitions  of  the  measures 

•  Collected  measures 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  quantitative  project 
management  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  quantitative 
project  management  process,  [gpiuj 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  quantitative  project  management  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 
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GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  quantitative 
project  management  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GP11  8] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  quantitative  project  management 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  [gpiwi 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  quantitative  project 
management  process  in  fulfilling  the  relevant  business  objectives 
of  the  organization.  1GP1251 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  quantitative  project  management  process.  [GP121] 
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ENGINEERING _ 

The  following  section  contains  all  of  the  process  areas  that  belong  to 
the  Engineering  process  area  category.  The  Engineering  process  areas 
of  CMMI  are  as  follows:  [fmios.tioi] 

•  Requirements  Management 

•  Requirements  Development 

•  Technical  Solution 

•  Product  Integration 

•  Verification 

•  Validation 

See  Chapter  5  for  more  information  about  the  Engineering  process 
areas  and  how  they  interact.  [fmio6.tio2] 


Engineering 
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REQUIREMENTS  MANAGEMENT 

Engineering 


Purpose 


The  purpose  of  Requirements  Management  is  to  manage  the 
requirements  of  the  project's  products  and  product  components  and  to 
identify  inconsistencies  between  those  requirements  and  the  project's 
plans  and  work  products.  [pai46] 


Introductory  Notes 


Requirements  management  processes  manage  all  requirements 
received  or  generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements  levied  on  the 
project  by  the  organization.  In  particular,  if  the  Requirements 
Development  process  area  is  implemented,  its  processes  will  generate 
product  and  product-component  requirements  that  will  also  be  managed 
by  the  requirements  management  processes.  When  the  Requirements 
Management,  Requirements  Development,  and  Technical  Solution 
process  areas  are  all  implemented,  their  associated  processes  may  be 
closely  tied  and  be  performed  concurrently.  [pai46.nioi] 

The  project  takes  appropriate  steps  to  ensure  that  the  agreed-upon  set 
of  requirements  is  managed  to  support  the  planning  and  execution 
needs  of  the  project.  When  a  project  receives  requirements  from  an 
approved  requirements  provider,  the  requirements  are  reviewed  with 
the  requirements  provider  to  resolve  issues  and  prevent 
misunderstanding  before  the  requirements  are  incorporated  into  the 
project’s  plans.  Once  the  requirements  provider  and  the  requirements 
receiver  reach  an  agreement,  commitment  to  the  requirements  is 
obtained  from  the  project  participants.  The  project  manages  changes  to 
the  requirements  as  they  evolve  and  identifies  any  inconsistencies  that 
occur  among  the  plans,  work  products,  and  requirements.  [pai46  nio2] 

Part  of  the  management  of  requirements  is  to  document  requirements 
changes  and  rationale  and  maintain  bidirectional  traceability  between 
source  requirements  and  all  product  and  product-component 
requirements.  [pai46.nio3] 
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Refer  to  the  Requirements  Development  process  area  for  more 
information  regarding  transforming  stakeholder  needs  into  product 
requirements  and  deciding  how  to  allocate  or  distribute  requirements 
among  the  product  components,  ipaub.rioii 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  technical  solutions.  [PAU6.R1021 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
how  project  plans  reflect  requirements  and  need  to  be  revised  as 
requirements  change.  [pau6.rio3] 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  baselines  and  controlling  changes  to  configuration 
documentation  for  requirements.  paub.rio4i 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  tracking  and  controlling  the  activities  and  work 
products  that  are  based  on  the  requirements  and  taking  appropriate 
corrective  action,  ipaub.riosi 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  handling  risks  associated  with  requirements.  [paub.riob] 


Specific  Goals 


SG  1  Manage  Requirements  [pam6igioi] 


Requirements  are  managed  and  inconsistencies  with  project  plans  and  work 
products  are  identified. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GG  2  Institutionalize  a  Managed  Process  [clio3.glioii 


The  process  is  institutionalized  as  a  managed  process. 
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GG  3  Institutionalize  a  Defined  Process  [clw.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 


SG  1  Manage  Requirements  [pai46.igioii 

SP  1.1-1  Obtain  an  Understanding  of  Requirements 

SP  1.2-2  Obtain  Commitment  to  Requirements 

SP  1.3-1  Manage  Requirements  Changes 

SP  1 .4-2  Maintain  Bidirectional  Traceability  of  Requirements 

SP  1 .5-1  Identify  Inconsistencies  between  Project  Work  and  Requirements 


GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 


GG  2  Institutionalize  a 
GP  2.1 
GP  2.2 
GP  2.3 
GP  2.4 
GP  2.5 
GP  2.6 
GP  2.7 
GP  2.8 
GP  2.9 
GP  2.10 


Managed  Process  [clkh.glioi] 

Establish  an  Organizational  Policy 

Plan  the  Process 

Provide  Resources 

Assign  Responsibility 

Train  People 

Manage  Configurations 

Identify  and  Involve  Relevant  Stakeholders 

Monitor  and  Control  the  Process 

Objectively  Evaluate  Adherence 

Review  Status  with  Higher  Level  Management 


GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 


GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 
GP  4.2  Stabilize  Subprocess  Performance 


GG  5  Institutionalize  an  Optimizing  Process  [cliobglioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 
GP  5.2  Correct  Root  Causes  of  Problems 
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Specific  Practices  by  Goal 


SG  1  Manage  Requirements 


Requirements  are  managed  and  inconsistencies  with  project  plans  and  work 
products  are  identified,  [paub.igioi] 

The  project  maintains  a  current  and  approved  set  of  requirements  over 
the  life  of  the  project  by  doing  the  following:  [pahb.igioi.nioi] 

•  Managing  all  changes  to  the  requirements 

•  Maintaining  the  relationships  between  the  requirements,  the  project 
plans,  and  the  work  products 

•  Identifying  inconsistencies  between  the  requirements,  the  project 
plans,  and  the  work  products 

•  Taking  corrective  action 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
determining  the  feasibility  of  the  requirements,  [pau6.igioi.nioi.rioi] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  ensuring  that  the  requirements  reflect  the  needs  and 
expectations  of  the  customer,  [pau6.igioi.nioi.rio2] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  taking  corrective  action,  [pau6.igioi.nioi.rio3] 

For  Software  Engineering 

The  requirements  may  be  a  subset  of  the  overall  product 
requirements,  or  they  may  constitute  the  entire  product 
requirements.  [pau6.igioi.ampioii 


SP  1.1-1  Obtain  an  Understanding  of  Requirements 

Develop  an  understanding  with  the  requirements  providers  on  the 
meaning  of  the  requirements,  i pau6.igioi.spioi / 


As  the  project  matures  and  requirements  are  derived,  all  activities  or 
disciplines  will  receive  requirements.  To  avoid  requirements  creep, 
criteria  are  established  to  designate  appropriate  channels,  or  official 
sources,  from  which  to  receive  requirements.  The  receiving  activities 
conduct  analyses  of  the  requirements  with  the  requirements  provider  to 
ensure  that  a  compatible,  shared  understanding  is  reached  on  the 
meaning  of  the  requirements.  The  result  of  this  analysis  and  dialog  is  an 
agreed-to  set  of  requirements,  [pah6.igioi.spioi.nioi] 


Engineering,  Requirements  Management 


325 


CMMI-SW,  vl.1 
Continuous  Representation 


Typical  Work  Products 

1 .  Lists  of  criteria  for  distinguishing  appropriate  requirements 

providers  [PA146.IG101.SP101.W101] 

2.  Criteria  for  evaluation  and  acceptance  of  requirements 

[PA146.IG101.SP101.W102] 

3.  Results  of  analyses  against  criteria  [pah6.igioi.spioi.wio3] 

4.  An  agreed-to  set  of  requirements  [pah6.igioi.spioi.wio4] 

Subpractices 

1 .  Establish  criteria  for  distinguishing  appropriate  requirements 
providers.  [PAH6.iGioi.spioi.subPioi] 

2.  Establish  objective  criteria  for  the  acceptance  of  requirements. 

[PA146.IG101.SP101.SubP102] 

Lack  of  acceptance  criteria  often  results  in  inadequate  verification,  costly  rework, 
or  customer  rejection.  [PAi46.iGi01.sp101.subPi02.Ni02] 

Examples  of  acceptance  criteria  include  the  following:  [PAi46.iGioi.spioi.subPio2.Nioi] 

•  Clearly  and  properly  stated 

•  Complete 

•  Consistent  with  each  other 

•  Uniquely  identified 

•  Appropriate  to  implement 

•  Verifiable  (testable) 

•  Traceable 

3.  Analyze  requirements  to  ensure  that  the  established  criteria  are 

met.  [PA146.IG101.SP101.SubP103] 

4.  Reach  an  understanding  of  the  requirements  with  the  requirements 
provider  so  the  project  participants  can  commit  to  them. 

[PA146.IG101.SP101.SubP104] 


SP  1.2-2  Obtain  Commitment  to  Requirements 

Obtain  commitment  to  the  requirements  from  the  project 
participants.  ipau6.igioi.spio2] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  the  commitments  made,  [pau6.igwi.spio2.rioi] 
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Whereas  the  previous  specific  practice  dealt  with  reaching  an 
understanding  with  the  requirements  providers,  this  specific  practice 
deals  with  agreements  and  commitments  among  those  who  have  to 
carry  out  the  activities  necessary  to  implement  the  requirements. 
Requirements  evolve  throughout  the  project,  especially  as  described  by 
the  specific  practices  of  the  Requirements  Development  process  area 
and  the  Technical  Solution  process  area.  As  the  requirements  evolve, 
this  specific  practice  ensures  that  project  participants  commit  to  the 
current,  approved  requirements  and  the  resulting  changes  in  project 
plans,  activities,  and  work  products,  [pai46.igioi.spio2.nioi] 

Typical  Work  Products 

1 .  Requirements  impact  assessments  [pai46.igioi.spio2.wioi] 

2.  Documented  commitments  to  requirements  and  requirements 

changes  [PAi46.IGi0i.SPi02.Wi02] 

Subpractices 

1 .  Assess  the  impact  of  requirements  on  existing  commitments. 

[PA146.IG101.SP102.SubP101] 

The  impact  on  the  project  participants  should  be  evaluated  when  the  requirements 
change  or  at  the  start  of  a  new  requirement.  [PAi46.iGioi.spio2.subPioi.Nioi] 

2.  Negotiate  and  record  commitments.  [PAi46.iGioi.spio2.subPio2] 

Changes  to  existing  commitments  should  be  negotiated  before  project  participants 
commit  to  the  requirement  or  requirement  change.  [PAi46.iGi01.sp102.subPi02.Ni0i] 


SP  1.3-1  Manage  Requirements  Changes 

Manage  changes  to  the  requirements  as  they  evolve  during  the 

project.  [PA146.IG101.SP103] 


Refer  to  the  Configuration  Management  process  area  for  more 
information  about  maintaining  and  controlling  the  requirements  baseline 
and  on  making  the  requirements  and  change  data  available  to  the 

project.  I PA146.IG101.SP103.R101 ] 

During  the  project,  requirements  change  for  a  variety  of  reasons.  As 
needs  change  and  as  work  proceeds,  additional  requirements  are 
derived  and  changes  may  have  to  be  made  to  the  existing 
requirements.  It  is  essential  to  manage  these  additions  and  changes 
efficiently  and  effectively.  To  effectively  analyze  the  impact  of  the 
changes,  it  is  necessary  that  the  source  of  each  requirement  is  known 
and  the  rationale  for  any  change  is  documented.  The  project  manager 
may,  however,  want  to  track  appropriate  measures  of  requirements 
volatility  to  judge  whether  new  or  revised  controls  are  necessary. 

[PA146.IG101.SP103.N101] 
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Typical  Work  Products 

1.  Requirements  status  [pai46.igioi.spio3.wioi] 

2.  Requirements  database  [pai46.igioi.spio3.wio2] 

3.  Requirements  decision  database  [pai46.igioi.spio3.wio3] 

Subpractices 

1 .  Capture  all  requirements  and  requirements  changes  that  are  given 
to  or  generated  by  the  project.  [PAi46.iGioi.spio3.subPioi] 

2.  Maintain  the  requirements  change  history  with  the  rationale  for  the 

Changes.  [PA146.IG101.SP103.SubP102] 

Maintaining  the  change  history  helps  track  requirements  volatility. 

[PA146.IG101.SP103.SubP102.N101] 

3.  Evaluate  the  impact  of  requirement  changes  from  the  standpoint  of 
relevant  stakeholders.  [PAi46.iGioi.spio3.subPio3] 

4.  Make  the  requirements  and  change  data  available  to  the  project. 

[PA146.IG101.SP103.SubP104] 


SP  1.4-2  Maintain  Bidirectional  Traceability  of  Requirements 

Maintain  bidirectional  traceability  among  the  requirements  and  the 
project  plans  and  work  products,  [paub.igioi.spw4] 


The  intent  of  this  specific  practice  is  to  maintain  the  bidirectional 
traceability  of  requirements  for  each  level  of  product  decomposition. 
When  the  requirements  are  managed  well,  traceability  can  be 
established  from  the  source  requirement  to  its  lower  level  requirements 
and  from  the  lower  level  requirements  back  to  their  source.  Such 
bidirectional  traceability  helps  determine  that  all  source  requirements 
have  been  completely  addressed  and  that  all  lower  level  requirements 
can  be  traced  to  a  valid  source.  Requirements  traceability  can  also 
cover  the  relationships  to  other  entities  such  as  intermediate  and  final 
work  products,  changes  in  design  documentation,  test  plans,  and  work 
tasks.  The  traceability  should  cover  both  the  horizontal  and  vertical 
relationships,  such  as  across  interfaces.  Traceability  is  particularly 
needed  in  conducting  the  impact  assessment  of  requirements  changes 
on  the  project  plans,  activities,  and  work  products,  [pai46.igioi.spio4.nioi] 

Typical  Work  Products 

1 .  Requirements  traceability  matrix  [pai46.igioi.spio4.wioi] 

2.  Requirements  tracking  system  [pai46.igioi.spio4.wio2] 
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Subpractices 

1 .  Maintain  requirements  traceability  to  ensure  that  the  source  of 
lower  level  (derived)  requirements  is  documented. 

[PA146.IG101.SP104.SubP101] 

2.  Maintain  requirements  traceability  from  a  requirement  to  its  derived 
requirements  as  well  as  to  its  allocation  of  functions,  objects, 
people,  processes,  and  work  products.  [PAi46.iGioi.spio4.subPio2] 

3.  Maintain  horizontal  traceability  from  function  to  function  and  across 
interfaces.  [PAi46.iGioi.spio4.subPio3] 

4.  Generate  the  requirements  traceability  matrix.  [pai46.igioi  spio4.subPio4] 


SP  1.5-1  Identify  Inconsistencies  between  Project  Work  and  Requirements 

Identify  inconsistencies  between  the  project  plans  and  work 
products  and  the  requirements,  [paub.igioi.spios] 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  monitoring  and  controlling  the  project  plans  and  work 
products  for  consistency  with  requirements  and  taking  corrective 
actions  when  necessary,  [pau6.igioi.spio5.rioi] 

This  specific  practice  finds  the  inconsistencies  between  the 
requirements  and  the  project  plans  and  work  products  and  initiates  the 
corrective  action  to  fix  them,  [pai46.igioi.spio5.nioi] 

Typical  Work  Products 

1.  Documentation  of  inconsistencies  including  sources,  conditions, 
and  rationale  [pai46.igioi.spio5.wioi] 

2.  Corrective  actions  [pai46.igioi.spio5.wio2] 

Subpractices 

1 .  Review  the  project's  plans,  activities,  and  work  products  for 
consistency  with  the  requirements  and  the  changes  made  to  them. 

[PA146.IG101.SP105.SubP101] 

2.  Identify  the  source  of  the  inconsistency  and  the  rationale. 

[PA146.IG101.SP105.SubP102] 

3.  Identify  changes  that  need  to  be  made  to  the  plans  and  work 
products  resulting  from  changes  to  the  requirements  baseline. 

[PA146.IG101.SP105.SubP103] 

4.  Initiate  corrective  actions.  [PAi46.iGioi.spio5.subPio4] 
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Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  requirements  management 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  requirements  management  process.  igpio3j 


Elaboration: 

This  policy  establishes  organizational  expectations  for  managing 
requirements  and  identifying  inconsistencies  between  the  requirements 
and  the  project  plans  and  work  products.  [pai46.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  requirements 
management  process,  [gpmj 


Elaboration: 

Typically,  this  plan  for  performing  the  requirements  management 
process  is  a  part  of  the  project  plan  as  described  in  the  Project  Planning 
process  area.  [pai46.elio2] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  requirements 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  igpiosj 
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Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pai46.elh3] 

•  Requirements  tracking  tools 

•  Traceability  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
requirements  management  process,  [g piosi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  requirements 
management  process  as  needed.  [gpio7] 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pamb.elios] 

•  Application  domain 

•  Requirements  definition,  analysis,  review,  and  management 

•  Requirements  management  tools 

•  Configuration  management 

•  Negotiation  and  conflict  resolution 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  requirements  management 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai46.elios] 

•  Requirements 

•  Requirements  traceability  matrix 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  requirements 
management  process  as  planned.  [GP1241 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process,  [pams.elhs] 


Examples  of  activities  for  stakeholder  involvement  include:  [pai46.elh6] 

•  Resolving  issues  on  the  understanding  of  the  requirements 

•  Assessing  the  impact  of  requirements  changes 

•  Communicating  the  bidirectional  traceability 

•  Identifying  inconsistencies  among  project  plans,  work  products,  and  requirements 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  requirements  management  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuo] 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA146.EL111] 

•  Requirements  volatility  (percentage  of  requirements  changed) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  requirements  management 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance.  [gph3] 


Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai46.elh2] 

•  Managing  requirements 

•  Identifying  inconsistencies  among  project  plans,  work  products,  and  requirements 
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Examples  of  work  products  reviewed  include  the  following:  [pai46.elh4] 

•  Requirements 

•  Requirements  traceability  matrix 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  requirements 
management  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


Elaboration: 

Proposed  changes  to  commitments  to  be  made  external  to  the 
organization  are  reviewed  with  higher  level  management  to  ensure  that 
all  commitments  can  be  accomplished.  [pai46.elh7] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  requirements 
management  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  requirements  management  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
requirements  management  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gpusi 
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GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  requirements  management  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  [gphsi 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  requirements  management 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP1251 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  requirements  management  process.  [GP121] 


334 


Engineering,  Requirements  Management 


CMMI-SW,  vl.1 
Continuous  Representation 


REQUIREMENTS  DEVELOPMENT 

Engineering 


Purpose 


The  purpose  of  Requirements  Development  is  to  produce  and  analyze 
customer,  product,  and  product-component  requirements.  [pais7] 


Introductory  Notes 


This  process  area  describes  three  types  of  requirements:  customer 
requirements,  product  requirements,  and  product-component 
requirements.  Taken  together,  these  requirements  address  the  needs  of 
relevant  stakeholders,  including  those  pertinent  to  various  product  life- 
cycle  phases  (e.g.,  acceptance  testing  criteria)  and  product  attributes 
(e.g.,  safety,  reliability,  maintainability).  Requirements  also  address 
constraints  caused  by  the  selection  of  design  solutions  (e.g.,  integration 
of  commercial  off-the-shelf  products).  [pai57.nioi] 

Requirements  are  the  basis  for  design.  The  development  of 
requirements  includes  the  following  activities:  [PA157  N102] 

•  Elicitation,  analysis,  validation,  and  communication  of  customer 
needs,  expectations,  and  constraints  to  obtain  customer 
requirements  that  constitute  an  understanding  of  what  will  satisfy 
stakeholders 

•  Collection  and  coordination  of  stakeholder  needs 

•  Development  of  the  life-cycle  requirements  of  the  product 

•  Establishment  of  the  customer  requirements 

•  Establishment  of  initial  product  and  product-component 
requirements  consistent  with  customer  requirements 

This  process  area  addresses  all  customer  requirements  rather  than  only 
product-level  requirements  because  the  customer  may  also  provide 
specific  design  requirements.  [pai57.nio3] 

Customer  requirements  are  further  refined  into  product  and  product- 
component  requirements.  In  addition  to  customer  requirements,  product 
and  product-component  requirements  are  derived  from  the  selected 
design  solutions.  [pai57.nio4] 
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Requirements  are  identified  and  refined  throughout  the  phases  of  the 
product  life  cycle.  Design  decisions,  subsequent  corrective  actions,  and 
feedback  during  each  phase  of  the  product’s  life  cycle  are  analyzed  for 
impact  on  derived  and  allocated  requirements.  [pais7.nio5] 

The  Requirements  Development  process  area  includes  three  specific 
goals.  The  Develop  Customer  Requirements  specific  goal  addresses 
defining  a  set  of  customer  requirements  to  use  in  the  development  of 
product  requirements.  The  Develop  Product  Requirements  specific  goal 
addresses  defining  a  set  of  product  or  product-component  requirements 
to  use  in  the  design  of  products  and  product  components.  The  Analyze 
and  Validate  Requirements  specific  goal  addresses  the  necessary 
analysis  of  customer,  product,  and  product-component  requirements  to 
define,  derive,  and  understand  the  requirements.  The  specific  practices 
of  the  third  specific  goal  are  intended  to  assist  the  specific  practices  in 
the  first  two  specific  goals.  The  processes  associated  with  the 
Requirements  Development  process  area  and  those  associated  with 
the  Technical  Solution  process  area  may  interact  recursively  with  one 
another,  [paw.nui] 

Analyses  are  used  to  understand,  define,  and  select  the  requirements 
at  all  levels  from  competing  alternatives.  These  analyses  include  the 
following:  [pais7.nio6] 

•  Analysis  of  needs  and  requirements  for  each  product  life-cycle 
phase,  including  needs  of  relevant  stakeholders,  the  operational 
environment,  and  factors  that  reflect  overall  customer  and  end-user 
expectations  and  satisfaction,  such  as  safety,  security,  and 
affordability 

•  Development  of  an  operational  concept 

•  Definition  of  the  required  functionality 

The  definition  of  functionality,  also  referred  to  as  “functional  analysis,”  is 
not  the  same  as  structured  analysis  in  software  development  and  does 
not  presume  a  functionally  oriented  software  design.  In  object-oriented 
software  design,  it  relates  to  defining  the  services.  The  definition  of 
functions,  their  logical  groupings,  and  their  association  with 
requirements  is  referred  to  as  a  “functional  architecture.”  [paw.nw] 

Analyses  occur  recursively  at  successively  more  detailed  layers  of  a 
product’s  architecture  until  sufficient  detail  is  available  to  enable 
detailed  design,  acquisition,  and  testing  of  the  product  to  proceed.  As  a 
result  of  the  analysis  of  requirements  and  the  operational  concept 
(including  functionality,  support,  maintenance,  and  disposal),  the 
manufacturing  or  production  concept  produces  more  derived 
requirements,  including  consideration  of  the  following:  [pai57  nios] 

•  Constraints  of  various  types 

•  Technological  limitations 
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•  Cost  and  cost  drivers 

•  Time  constraints  and  schedule  drivers 

•  Risks 

•  Consideration  of  issues  implied  but  not  explicitly  stated  by  the 
customer  or  end  user 

•  Factors  introduced  by  the  developer’s  unique  business 
considerations,  regulations,  and  laws 

A  hierarchy  of  logical  entities  (functions  and  subfunctions,  object 
classes  and  subclasses)  is  established  through  iteration  with  the 
evolving  operational  concept.  Requirements  are  refined,  derived,  and 
allocated  to  these  logical  entities.  Requirements  and  logical  entities  are 
allocated  to  products,  product  components,  people,  associated 
processes,  or  services.  [PA157.N109] 


Involvement  of  relevant  stakeholders  in  both  requirements  development 
and  analysis  gives  them  visibility  into  the  evolution  of  requirements. 

This  activity  continually  assures  them  that  the  requirements  are  being 
properly  defined,  [paw.nhoi 


Related  Process  Areas 


Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  customer  and  product  requirements, 
obtaining  agreement  with  the  requirements  provider,  obtaining 
commitments  with  those  implementing  the  requirements,  and 
maintaining  traceability.  [pais7.rioi] 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
how  the  outputs  of  the  requirements  development  processes  are  used, 
and  the  development  of  alternative  solutions  and  designs  used  in 
refining  and  deriving  requirements.  [pais7.rio2] 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  interface  requirements  and  interface  management.  [pais7.rio3] 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  that  the  resulting  product  meets  the  requirements.  [pais7.rio4] 

Refer  to  the  Validation  process  area  for  more  information  about  how  the 
product  built  will  be  validated  against  the  customer  needs,  [paiszrios] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  managing  risks  that  are  related  to  requirements.  [pais7.rio6] 
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Refer  to  the  Configuration  Management  process  area  for  information 
about  ensuring  that  key  work  products  are  controlled  and  managed. 

[PA157.R107] 

Specific  Goals 


SG  1  Develop  Customer  Requirements  [paisz.igioi] 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and 
translated  into  customer  requirements. 


SG  2  Develop  Product  Requirements  [PA157.1G103] 

Customer  requirements  are  refined  and  elaborated  to  develop  product  and 
product-component  requirements. 


SG  3  Analyze  and  Validate  Requirements  [PA157.1G102] 

The  requirements  are  analyzed  and  validated,  and  a  definition  of  required 
functionality  is  developed. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 
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Practice-to-Goal  Relationship  Table 

SG  1  Develop  Customer  Requirements  [paisz.igioi] 

SP  1.1-1  Collect  Stakeholder  Needs 
SP  1.1-2  Elicit  Needs 

SP  1 .2-1  Develop  the  Customer  Requirements 

SG  2  Develop  Product  Requirements  [pai57.igio3] 

SP  2.1-1  Establish  Product  and  Product-Component  Requirements 
SP  2.2-1  Allocate  Product-Component  Requirements 

SP  2.3-1  Identify  Interface  Requirements 

SG  3  Analyze  and  Validate  Requirements  [pais7.igio2] 

SP  3.1-1  Establish  Operational  Concepts  and  Scenarios 
SP  3.2-1  Establish  a  Definition  of  Required  Functionality 
SP  3.3-1  Analyze  Requirements 

SP  3.4-3  Analyze  Requirements  to  Achieve  Balance 

SP  3.5-1  Validate  Requirements 

SP  3.5-2  Validate  Requirements  with  Comprehensive  Methods 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clioaglioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 

SG  1  Develop  Customer  Requirements 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and 
translated  into  customer  requirements.  [pais7.igioi] 
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The  needs  of  stakeholders  (e.g.,  customers,  end  users,  suppliers, 
builders,  and  testers)  are  the  basis  for  determining  customer 
requirements.  The  stakeholder  needs,  expectations,  constraints, 
interfaces,  operational  concepts,  and  product  concepts  are  analyzed, 
harmonized,  refined,  and  elaborated  for  translation  into  a  set  of 
customer  requirements,  [pais7.igioi.nioi] 

Frequently,  stakeholder  needs,  expectations,  constraints,  and  interfaces 
are  poorly  identified  or  conflicting.  Since  stakeholder  needs, 
expectations,  constraints,  and  limitations  should  be  clearly  identified 
and  understood,  an  iterative  process  is  used  throughout  the  life  of  the 
project  to  accomplish  this  objective.  To  facilitate  the  required 
interaction,  a  surrogate  for  the  end  user  or  customer  is  frequently 
involved  to  represent  their  needs  and  help  resolve  conflicts.  The 
customer  relations  or  marketing  part  of  the  organization  as  well  as 
members  of  the  development  team  from  disciplines  such  as  human 
engineering  or  support  can  be  used  as  surrogates.  Environmental, 
legal,  and  other  constraints  should  be  considered  when  creating  and 
resolving  the  set  of  customer  requirements,  [pai57.igioi.nio2] 


SP  1.1-1  Collect  Stakeholder  Needs 

Identify  and  collect  stakeholder  needs,  expectations,  constraints, 
and  interfaces  for  all  phases  of  the  product  life  cycle,  [pais7.igwi.spwi] 


In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Elicit  Needs  specific  practice. 

The  basic  activity  addresses  the  receipt  of  requirements  that  a 
customer  provides  to  define  what  is  needed  or  desired.  These 
requirements  may  or  may  not  be  stated  in  technical  terms.  They  should 
address  the  various  product  life-cycle  activities  and  their  impact  on  the 

prOdUCt.  [PA157.IG101.SP101.N101] 


SP  1.1-2  Elicit  Needs 

Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces 
for  all  phases  of  the  product  life  cycle,  [pais7.igwi.spw2] 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Collect 
Stakeholder  Needs  specific  practice. 

Eliciting  goes  beyond  collecting  requirements  by  proactively  identifying 
additional  requirements  not  explicitly  provided  by  customers.  Additional 
requirements  should  address  the  various  product  life-cycle  activities 
and  their  impact  on  the  product,  [pai57.igioi.spio2.nio2] 
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Examples  of  techniques  to  elicit  needs  include  the  following:  [pai57.igioi.spio2.nio3] 

•  Technology  demonstrations 

•  Interface  control  working  groups 

•  Technical  control  working  groups 

•  Interim  project  reviews 

•  Questionnaires,  interviews,  and  operational  scenarios  obtained  from  end  users 

•  Operational  walkthroughs  and  end-user  task  analysis 

•  Prototypes  and  models 

•  Brainstorming 

•  Quality  Function  Deployment 

•  Market  surveys 

•  Beta  testing 

•  Extraction  from  sources  such  as  documents,  standards,  or  specifications 

•  Observation  of  existing  products,  environments,  and  workflow  patterns 

•  Use  cases 

•  Business  case  analysis 

•  Reverse  engineering  (for  legacy  products) 


Subpractices 

1 .  Engage  relevant  stakeholders  using  methods  for  eliciting  needs, 
expectations,  constraints,  and  external  interfaces. 

[PA157.IG101.SP102.SubP101] 


SP  1.2-1  Develop  the  Customer  Requirements 

Transform  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  customer  requirements.  [pais7.igioi.spio3] 


The  various  inputs  from  the  customer  must  be  consolidated,  missing 
information  must  be  obtained,  and  conflicts  must  be  resolved  in 
documenting  the  recognized  set  of  customer  requirements.  The 
customer  requirements  may  include  needs,  expectations,  and 
constraints  with  regard  to  verification  and  validation,  [pai57.igioi.spio3.nioi] 

Typical  Work  Products 

1.  Customer  requirements  [pai57.igioi.spio3.wioi] 

2.  Customer  constraints  on  the  conduct  of  verification 

[PA157.IG101.SP103.W102] 

3.  Customer  constraints  on  the  conduct  of  validation  [pai57.igioi.spio3.wio3] 
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Subpractices 

1.  Translate  the  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  documented  customer  requirements. 

[PA157.IG101.SP103.SubP101] 

2.  Define  constraints  for  verification  and  validation.  [PAi57.iGioi.spio3.subPio2] 


SG  2  Develop  Product  Requirements 


Customer  requirements  are  refined  and  elaborated  to  develop  product  and 
product-component  requirements.  ipais7.igio3] 

Customer  requirements  are  analyzed  in  conjunction  with  the 
development  of  the  operational  concept  to  derive  more  detailed  and 
precise  sets  of  requirements  called  “product  and  product-component 
requirements.”  Product  and  product-component  requirements  address 
the  needs  associated  with  each  product  life-cycle  phase.  Derived 
requirements  arise  from  constraints,  consideration  of  issues  implied  but 
not  explicitly  stated  in  the  customer  requirements  baseline,  and  factors 
introduced  by  the  selected  architecture,  the  design,  and  the  developer’s 
unique  business  considerations.  The  requirements  are  reexamined  with 
each  successive,  lower  level  set  of  requirements  and  functional 
architecture,  and  the  preferred  product  concept  is  refined,  [pai57.igio3.nioi] 

The  requirements  are  allocated  to  product  functions  and  product 
components  including  objects,  people,  and  processes.  The  traceability 
of  requirements  to  functions,  objects,  tests,  issues,  or  other  entities  is 
documented.  The  allocated  requirements  and  functions  are  the  basis  for 
the  synthesis  of  the  technical  solution.  As  internal  components  are 
developed,  additional  interfaces  are  defined  and  interface  requirements 
established,  [pai57.igio3.nio2] 

Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements  specific 
practice  of  the  Requirements  Management  process  area  for  more 
information  about  maintaining  bidirectional  traceability,  [pais7.igio3.nw2.rioi] 


SP  2.1-1  Establish  Product  and  Product-Component  Requirements 

Establish  and  maintain  product  and  product-component 
requirements,  which  are  based  on  the  customer  requirements. 

[PA1 57.IG1 03.SP1 01] 
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The  customer  requirements  may  be  expressed  in  the  customer’s  terms 
and  may  be  nontechnical  descriptions.  The  product  requirements  are 
the  expression  of  these  requirements  in  technical  terms  that  can  be 
used  for  design  decisions.  An  example  of  this  translation  is  found  in  the 
first  House  of  Quality  Functional  Deployment,  which  maps  customer 
desires  into  technical  parameters.  For  instance,  “solid  sounding  door” 
might  be  mapped  to  size,  weight,  fit,  dampening,  and  resonant 
frequencies,  [pai57.igio3.spioi.nioi] 

Product  and  product-component  requirements  address  the  satisfaction 
of  customer,  business,  and  project  objectives  and  associated  attributes, 
such  as  effectiveness  and  affordability,  [pai57.igio3.spioi.nio4] 

Design  constraints  include  specifications  on  product  components  that 
are  derived  from  design  decisions,  rather  than  higher  level 

requirements,  [pai57.igio3.spioi.nio2] 

For  Software  Engineering 

For  example ,  application  components  that  must  interface  with  an  off-the- 
shelf  database  component  must  comply  with  interface  requirements 
imposed  by  the  selected  database.  Such  product-component  requirements 
are  generally  not  traceable  to  higher  level  requirements. 

[PA157.IG103.SP1 01. N102.AMP1 01] 


Derived  requirements  also  address  the  cost  and  performance  of  other 
life-cycle  phases  (e.g.,  production,  operations,  and  disposal)  to  the 
extent  compatible  with  business  objectives,  [pais7.igio3.spioi.nio3] 

The  modification  of  requirements  due  to  approved  requirement  changes 
is  covered  by  the  “maintain”  function  of  this  specific  practice;  whereas, 
the  administration  of  requirement  changes  is  covered  by  the 
Requirements  Management  process  area,  [pai57.igio3.spioi.nio5] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  changes  to  requirements. 

[PA157.IG103.SP101.N105.R101] 

Typical  Work  Products 

1.  Derived  requirements  [pai57.igio3.spioi.wioi] 

2.  Product  requirements  [PAi57.iGi03.sp101.w102] 

3.  Product-component  requirements  [pai57.igio3.spioi.wio3] 

Subpractices 

1 .  Develop  requirements  in  technical  terms  necessary  for  product  and 
product-component  design.  [PAi57.iGio3.spioi.subPioi] 

Develop  architecture  requirements  addressing  critical  product  qualities  and 
performance  necessary  for  product  architecture  design.  [PAi57.iGi03.sp101.subPi01.Ni0i] 
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2.  Derive  requirements  that  result  from  design  decisions. 

[PA1 57.IG1 03.SP1 01  .SubPI  02] 

Refer  to  the  Technical  Solution  process  area  for  more  information 
about  developing  the  solutions  that  generate  additional  derived 
requirements.  [PAi57.iGi03.sp101.subPi02.Ri0i] 

Selection  of  a  technology  brings  with  it  additional  requirements.  For  instance,  use 
of  electronics  requires  additional  technology-specific  requirements  such  as 
electromagnetic  interference  limits.  [PAi57.iGio3.sp101.subPio2.Nioi] 

3.  Establish  and  maintain  relationships  between  requirements  for 
consideration  during  change  management  and  requirements 

allocation.  [PA157.IG103.SP101.SubP103] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability. 

[PA157.IG103.SP101.SubP103.R101] 


Relationships  between  requirements  can  aid  in  evaluating  the  impact  of  changes. 

[PA157.IG103.SP101.SubP103.N101] 


SP  2.2-1  Allocate  Product-Component  Requirements 

Allocate  the  requirements  for  each  product  component. 

[PA157.IG103.SP1 02] 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
allocation  of  requirements  to  products  and  product  components.  This 
specific  practice  provides  information  for  defining  the  allocation  of 
requirements  but  must  interact  with  the  specific  practices  in  the 
Technical  Solution  process  area  to  establish  solutions  to  which  the 
requirements  are  allocated,  [pai57.igw3.spio2.rwi] 

The  requirements  for  product  components  of  the  defined  solution 
include  allocation  of  product  performance;  design  constraints;  and  fit, 
form,  and  function  to  meet  requirements  and  facilitate  production.  In 
cases  where  a  higher  level  requirement  specifies  performance  that  will 
be  the  responsibility  of  two  or  more  product  components,  the 
performance  must  be  partitioned  for  unique  allocation  to  each  product 
component  as  a  derived  requirement,  [pai57.igio3.spio2.nioi] 

Typical  Work  Products 

1 .  Requirement  allocation  sheets  [PAi57.iGi03.sp102.w10i] 

2.  Provisional  requirement  allocations  [PAi57.iGi03.sp102.w102] 

3.  Design  constraints  [PAi57.iGi03.sp102.w103] 

4.  Derived  requirements  [PAi57.iGi03.sp102.w104] 
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5.  Relationships  among  derived  requirements  [PAi57.iGi03.sp102.w105] 

Subpractices 

1 .  Allocate  requirements  to  functions.  [PAi57.iGio3.spio2.subPioi] 

2.  Allocate  requirements  to  product  components.  [PAi57.iGio3.spio2.subPio2] 

3.  Allocate  design  constraints  to  product  components. 

[PA157.IG103.SP102.SubP103] 

4.  Document  relationships  among  allocated  requirements. 

[PA157.IG103.SP102.SubP104] 

Relationships  include  dependencies  in  which  a  change  in  one  requirement  may 
affect  other  requirements.  [PAi57.iGio3.sp102.subPio4.Nioi] 


SP  2.3-1  Identify  Interface  Requirements 

Identify  interface  requirements,  [pm57.igio3.spw3] 


Interfaces  between  functions  (or  between  objects)  are  identified. 
Functional  interfaces  may  drive  the  development  of  alternative  solutions 
described  in  the  Technical  Solution  process  area,  [pais7.igio3.spio3.nioi] 

Refer  to  the  Product  Integration  process  area  for  more  information 
about  the  management  of  interfaces  and  the  integration  of  products  and 
product  components,  [pais7.igio3.spio3.nioi.rioi] 

Interface  requirements  between  products  or  product  components 
identified  in  the  product  architecture  are  defined.  They  are  controlled  as 
part  of  product  and  product-component  integration  and  are  an  integral 
part  of  the  architecture  definition,  [pai57.igio3.spio3.nio2] 

Typical  Work  Products 

1.  Interface  requirements  [pai57.igio3.spio3.wioi] 

Subpractices 

1 .  Identify  interfaces  both  external  to  the  product  and  internal  to  the 
product  (i.e.,  between  functional  partitions  or  objects). 

[PA157.1G103.SP1 03. SubPI  01] 


As  the  design  progresses,  the  product  architecture  will  be  altered  by  technical 
solution  processes,  creating  new  interfaces  between  product  components  and 
components  external  to  the  product.  [PAi57.iGi03.sp103.subPi01.Ni0i] 

Interfaces  with  product-related  life-cycle  processes  should  also  be  identified. 

[PA157.IG103.SP103.SubP101.N102] 
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Examples  of  these  interfaces  include  interfaces  with  test  equipment, 
transportation  systems,  support  systems,  and  manufacturing  facilities. 

[PA157.IG103.SP103.SubP101.N103] 


2.  Develop  the  requirements  for  the  identified  interfaces. 

[PA157.IG103.SP103.SubP102] 


Refer  to  the  Technical  Solution  process  area  for  more  information 
about  generating  new  interfaces  during  the  design  process. 

[PA157.IG103.SP103.SubP102.R101] 


Requirements  for  interfaces  are  defined  in  terms  of  origination,  destination, 
stimulus,  data  characteristics  for  software,  and  electrical  and  mechanical 
characteristics  for  hardware.  [PAi57.iGi03.sp103.subPi02.Ni02] 


SG  3  Analyze  and  Validate  Requirements 


The  requirements  are  analyzed  and  validated,  and  a  definition  of  required 
functionality  is  developed.  [pais7.igio2] 

The  specific  practices  of  the  Analyze  and  Validate  Requirements 
specific  goal  support  the  development  of  the  requirements  in  both  the 
Develop  Customer  Requirements  specific  goal  and  the  Develop  Product 
Requirements  specific  goal.  The  specific  practices  associated  with  this 
specific  goal  cover  analyzing  and  validating  the  requirements  with 
respect  to  the  user’s  intended  environment,  [pai57.igio2.nio4] 

Analyses  are  performed  to  determine  what  impact  the  intended 
operational  environment  will  have  on  the  ability  to  satisfy  the 
stakeholders'  needs,  expectations,  constraints,  and  interfaces. 
Considerations  such  as  feasibility,  mission  needs,  cost  constraints, 
potential  market  size,  and  acquisition  strategy  must  all  be  taken  into 
account,  depending  on  the  product  context.  A  definition  of  required 
functionality  is  also  established.  All  specified  usage  modes  for  the 
product  are  considered,  and  a  timeline  analysis  is  generated  for  time- 
critical  sequencing  of  functions.  [PAi57.iGio2.Nioi] 

The  objectives  of  the  analyses  are  to  determine  candidate  requirements 
for  product  concepts  that  will  satisfy  stakeholder  needs,  expectations, 
and  constraints;  and  then  translate  these  concepts  into  requirements.  In 
parallel  with  this  activity,  the  parameters  that  will  be  used  to  evaluate 
the  effectiveness  of  the  product  are  determined  based  on  customer 
input  and  the  preliminary  product  concept.  [PAi57.iGi02.Ni02] 

Requirements  are  validated  to  increase  the  probability  that  the  resulting 
product  will  perform  as  intended  in  the  use  environment.  [PAi57.iGi02.Ni03] 
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SP  3.1-1  Establish  Operational  Concepts  and  Scenarios 

Establish  and  maintain  operational  concepts  and  associated 
scenarios,  [pai57.igio2.spwi] 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
detailed  development  of  operational  concepts  that  are  dependent  on  the 
selected  designs,  pai57.igio2.spioi.rioi] 

A  scenario  is  a  sequence  of  events  that  might  occur  in  the  use  of  the 
product,  which  is  used  to  make  explicit  some  of  the  needs  of  the 
stakeholders.  In  contrast,  an  operational  concept  for  a  product  usually 
depends  on  both  the  design  solution  and  the  scenario.  For  example,  the 
operational  concept  for  a  satellite-based  communications  product  is 
quite  different  from  one  based  on  landlines.  Since  the  alternative 
solutions  have  not  usually  been  defined  when  preparing  the  initial 
operational  concepts,  conceptual  solutions  are  developed  for  use  when 
analyzing  the  requirements.  The  operational  concepts  are  refined  as 
solution  decisions  are  made  and  lower  level  detailed  requirements  are 

developed.  [PA157.IG102.SP101.N101] 

Just  as  a  design  decision  for  a  product  may  become  a  requirement  for 
product  components,  the  operational  concept  may  become  the 
scenarios  (requirements)  for  product  components,  [pais7.igio2.spioi.nio2] 

The  scenarios  may  include  operational  sequences,  provided  those 
sequences  are  an  expression  of  customer  requirements  rather  than 
operational  concepts.  [pai57.igio2.spioi  nio3] 

Typical  Work  Products 

1.  Operational  concept  [pai57.igio2.spioi.wioi] 

2.  Product  installation,  operational,  maintenance,  and  support 

concepts  [PA157.IG102.SP101.W102] 

3.  Disposal  concepts  [pai57.igio2.spioi.wio3] 

4.  Use  cases  [PAi57.IGi02.SPi0i.Wi04] 

5.  Timeline  scenarios  [PAi57.iGi02.sp101.w105] 

6.  New  requirements  [pai57.igio2.spioi.wio6] 

Subpractices 

1 .  Develop  operational  concepts  and  scenarios  that  include 

functionality,  performance,  maintenance,  support,  and  disposal  as 
appropriate.  [PAi57.iGio2.spioi.subPioi] 

Identify  and  develop  scenarios,  consistent  with  the  level  of  detail  in  the 
stakeholder  needs,  expectations,  and  constraints,  in  which  the  proposed  product 
is  expected  to  operate.  [PAi57.iGio2.sp101.subPio1.Nioi] 
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2.  Define  the  environment  the  product  will  operate  in,  including 
boundaries  and  constraints.  [PAi57.iGio2.spioi.subPio2] 

3.  Review  operational  concepts  and  scenarios  to  refine  and  discover 
requirements.  [PAi57.iGio2.spioi.subPio3] 

Operational  concept  and  scenario  development  is  an  iterative  process.  The 
reviews  should  be  held  periodically  to  ensure  that  they  agree  with  the 
requirements.  The  review  may  be  in  the  form  of  a  walkthrough. 

[PA157.IG102.SP101.SubP103.N101] 

4.  Develop  a  detailed  operational  concept,  as  products  and  product 
components  are  selected,  that  defines  the  interaction  of  the 
product,  the  end  user,  and  the  environment,  and  that  satisfies  the 
operational,  maintenance,  support,  and  disposal  needs. 

[PA157.IG102.SP101.SubP104] 


SP  3.2-1  Establish  a  Definition  of  Required  Functionality 

Establish  and  maintain  a  definition  of  required  functionality. 

[PA157.IG102.SP1 02] 


The  definition  of  functionality,  also  referred  to  as  “functional  analysis,”  is 
the  description  of  what  the  product  is  intended  to  do.  The  definition  of 
functionality  can  include  actions,  sequence,  inputs,  outputs,  or  other 
information  that  communicates  the  manner  in  which  the  product  will  be 

USed.  [PA157.IG102.SP102.N101] 

Functional  analysis  is  not  the  same  as  structured  analysis  in  software 
development  and  does  not  presume  a  functionally  oriented  software 
design.  In  object-oriented  software  design,  it  relates  to  defining  the 
services.  The  definition  of  functions,  their  logical  groupings,  and  their 
association  with  requirements  is  referred  to  as  a  functional  architecture. 
See  the  definition  of  “functional  architecture”  in  Appendix  C,  the 

glossary.  [PA157.IG102.SP102.N102] 

Typical  Work  Products 

1.  Functional  architecture  [PAi57.iGi02.sp102.w10i] 

2.  Activity  diagrams  and  use  cases  [PAi57.iGi02.sp102.w102] 

3.  Object-oriented  analysis  with  services  identified  [PAi57.iGi02.sp102.w103] 

Subpractices 

1 .  Analyze  and  quantify  functionality  required  by  end  users. 

[PA157.IG102.SP1 02. SubPI  01] 

2.  Analyze  requirements  to  identify  logical  or  functional  partitions 
(e.g.,  subfunctions).  [PAi57.iGio2.spio2.subPio2] 
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3.  Partition  requirements  into  groups,  based  on  established  criteria 
(e.g.,  similar  functionality,  performance,  or  coupling),  to  facilitate 
and  focus  the  requirements  analysis.  [PAi57.iGio2.spio2.subPio3] 

4.  Consider  the  sequencing  of  time-critical  functions  both  initially  and 
subsequently  during  product-component  development. 

[PA157.IG102.SP102.SubP104] 

5.  Allocate  customer  requirements  to  functional  partitions,  objects, 
people,  or  support  elements  to  support  the  synthesis  of  solutions. 

[PA157.IG102.SP102.SubP105] 

6.  Allocate  functional  and  performance  requirements  to  functions  and 

subfunctions.  [PA157.IG102.SP102.SubP106] 


SP  3.3-1  Analyze  Requirements 

Analyze  requirements  to  ensure  that  they  are  necessary  and 

sufficient.  [ PA157.IG102.SP103 ] 


In  light  of  the  operational  concept  and  scenarios,  the  requirements  for 
one  level  of  the  product  hierarchy  are  analyzed  to  determine  whether 
they  are  necessary  and  sufficient  to  meet  the  objectives  of  higher  levels 
of  the  product  hierarchy.  The  analyzed  requirements  then  provide  the 
basis  for  more  detailed  and  precise  requirements  for  lower  levels  of  the 
product  hierarchy.  [PAi57.iGi02.sp103.Ni02] 

As  requirements  are  defined,  their  relationship  to  higher  level 
requirements  and  the  higher  level  defined  functionality  must  be 
understood.  One  of  the  other  actions  is  the  determination  of  which  key 
requirements  will  be  used  to  track  technical  progress.  For  instance,  the 
weight  of  a  product  or  size  of  a  software  product  may  be  monitored 
through  development  based  on  its  risk,  [pai57.igio2.spio3.nioi] 

Typical  Work  Products 

1.  Requirements  defects  reports  [pai57.igio2.spio3.wioi] 

2.  Proposed  requirements  changes  to  resolve  defects 

[PA157.IG102.SP103.W102] 

3.  Key  requirements  [PAi57.iGi02.sp103.w103] 

4.  Technical  performance  measures  [pai57.igio2.spio3.wio4] 

Subpractices 

1.  Analyze  stakeholder  needs,  expectations,  constraints,  and  external 
interfaces  to  remove  conflicts  and  to  organize  into  related  subjects. 

[PA157.1G102.SP1 03. SubPI  01] 
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2.  Analyze  requirements  to  determine  whether  they  satisfy  the 
objectives  of  higher  level  requirements.  [PAi57.iGio2.spio3.subPio2] 

3.  Analyze  requirements  to  ensure  that  they  are  complete,  feasible, 
realizable,  and  verifiable.  [PAi57.iGio2.spio3.subPio3] 

While  design  determines  the  feasibility  of  a  particular  solution,  this  subpractice 
addresses  knowing  which  requirements  affect  feasibility.  [PAi57.iGi02.sp103.subPi03.Ni0i] 

4.  Identify  key  requirements  that  have  a  strong  influence  on  cost, 
schedule,  functionality,  risk,  or  performance.  [PAi57.iGio2.spio3.subPio4] 

5.  Identify  technical  performance  measures  that  will  be  tracked  during 
the  development  effort.  [PAi57.iGio2.spio3.subPios] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  the  use  of  measurements.  pM57.iGi02.sp103.subPi05.Ri0i] 

6.  Analyze  operational  concepts  and  scenarios  to  refine  the  customer 
needs,  constraints,  and  interfaces  and  to  discover  new 
requirements.  [PAi57.iGio2.spio3.subPio6] 

This  analysis  may  result  in  more  detailed  operational  concepts  and  scenarios  as 
well  as  supporting  the  derivation  of  new  requirements.  [PAi57.iGio2.sp103.subPioe.Nioi] 


SP  3.4-3  Analyze  Requirements  to  Achieve  Balance 

Analyze  requirements  to  balance  stakeholder  needs  and 
constraints,  pais7.igio2.spw4] 

Stakeholder  needs  and  constraints  can  address  cost,  schedule, 
performance,  functionality,  reusable  components,  maintainability,  or 

risk.  [PA157.IG102.SP104.N102] 

Typical  Work  Products 

1 .  Assessment  of  risks  related  to  requirements  [pai57.igio2.spio4.wioi] 

Subpractices 

1.  Use  proven  models,  simulations,  and  prototyping  to  analyze  the 
balance  of  stakeholder  needs  and  constraints.  [PAi57.iGio2.spio4.subPio3] 

Results  of  the  analyses  can  be  used  to  reduce  the  cost  of  the  product  and  the  risk 
in  developing  the  product.  [PAi57.iGio2.sp104.subPio3.Nioi] 

2.  Perform  a  risk  assessment  on  the  requirements  and  functional 
architecture.  [PAi57.iGio2.spio4.subPioi] 

Refer  to  the  Risk  Management  process  area  for  information  about 
performing  a  risk  assessment  on  customer  and  product 
requirements  and  the  functional  architecture.  [PAi57.iGi02.sp104.subPi01.Ri0i] 
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3.  Examine  product  life-cycle  concepts  for  impacts  of  requirements  on 

riSkS.  [PA157.IG102.SP104.SubP102] 


SP  3.5-1  Validate  Requirements 

Validate  requirements  to  ensure  the  resulting  product  will  perform 
appropriately  in  its  intended-use  environment,  [pai57.igw2.spw5] 


In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Validate  Requirements  with  Comprehensive 
Methods  specific  practice. 

Typical  Work  Products 

1 .  Results  of  requirements  validation  [pai57.igio2.spio5.wioi] 

Subpractices 

1 .  Analyze  the  requirements  to  determine  the  risk  that  the  resulting 
product  will  not  perform  appropriately  in  its  intended-use 
environment.  [PAi57.iGio2.spio5.subPioi] 


SP  3.5-2  Validate  Requirements  with  Comprehensive  Methods 

Validate  requirements  to  ensure  the  resulting  product  will  perform 
as  intended  in  the  user's  environment  using  multiple  techniques 
as  appropriate,  [pais7.igw2.spw6] 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Validate 
Requirements  specific  practice. 

Requirements  validation  is  performed  early  in  the  development  effort  to 
gain  confidence  that  the  requirements  are  capable  of  guiding  a 
development  that  results  in  successful  final  validation.  This  activity 
should  be  integrated  with  risk  management  activities.  Mature 
organizations  will  typically  perform  requirements  validation  in  a  more 
sophisticated  way  and  will  broaden  the  basis  of  the  validation  to  include 
other  stakeholder  needs  and  expectations.  These  organizations  will 
typically  perform  analyses,  simulations,  or  prototypes  to  ensure  that 
requirements  will  satisfy  stakeholder  needs  and  expectations. 

[PA157.IG102.SP106.N102] 

Typical  Work  Products 

1 .  Record  of  analysis  methods  and  results  [pai57.igio2.spio6.wioi] 

Subpractices 

1 .  Analyze  the  requirements  to  determine  the  risk  that  the  resulting 
product  will  not  perform  appropriately  in  its  intended-use 
environment.  [PAi57.iGio2.spio6.subPioi] 
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2.  Explore  the  adequacy  and  completeness  of  requirements  by 
developing  product  representations  (e.g.,  prototypes,  simulations, 
models,  scenarios,  and  storyboards)  and  by  obtaining  feedback 
about  them  from  relevant  stakeholders.  [PAi57.iGio2.spio6.subPio2] 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  requirements 
validation  environment  to  identify  validation  issues  and  expose 
unstated  needs  and  customer  requirements.  [PAi57.iGio2.spio6.subPio3] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  requirements  development 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  igpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  requirements  development  process.  igpio3j 


Elaboration: 

This  policy  establishes  organizational  expectations  for  collecting 
stakeholder  needs,  formulating  product  and  product-component 
requirements,  and  analyzing  and  validating  those  requirements. 

[PA157.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  requirements 
development  process.  [gpio4] 
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Elaboration: 

Typically,  this  plan  for  performing  the  requirements  development 
process  is  a  part  of  the  project  plan  as  described  in  the  Project  Planning 
process  area.  [PA157.EL102] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  requirements 
development  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpios] 


Elaboration: 

Special  expertise  in  the  application  domain,  methods  for  eliciting 
stakeholder  needs,  and  methods  and  tools  for  specifying  and  analyzing 
customer,  product,  and  product-component  requirements  may  be 
required.  [pais7.elio3] 

Examples  of  other  resources  provided  include  the  following  tools:  [pais7.elio4] 

•  Requirements  specification  tools 

•  Simulators  and  modeling  tools 

•  Prototyping  tools 

•  Scenario  definition  and  management  tools 

•  Requirements  tracking  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
requirements  development  process,  [g pios] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  requirements 
development  process  as  needed,  i gpio7i 
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Elaboration: 

Examples  of  training  topics  include  the  following:  [pai57.elios] 

•  Application  domain 

•  Requirements  definition  and  analysis 

•  Requirements  elicitation 

•  Requirements  specification  and  modeling 

•  Requirements  tracking 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  requirements  development 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais7.elio6] 

•  Customer  requirements 

•  Functional  architecture 

•  Product  and  product-component  requirements 

•  Interface  requirements 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  requirements 
development  process  as  planned.  igpi24] 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process.  [pai57.elh3] 
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Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai57.elh4] 

•  Reviewing  the  adequacy  of  requirements  in  meeting  needs,  expectations, 
constraints,  and  interfaces 

•  Establishing  operational  concepts  and  scenarios 

•  Assessing  the  adequacy  of  requirements 

•  Establishing  product  and  product-component  requirements 

•  Assessing  product  cost,  schedule,  and  risk 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  requirements  development  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuoi 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA157.EL110] 

•  Cost,  schedule,  and  effort  expended  for  rework 

•  Defect  density  of  requirements  specifications 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  requirements  development 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance.  [gpu3] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [paw.elih] 

•  Collecting  stakeholder  needs 

•  Formulating  product  and  product-component  requirements 

•  Analyzing  and  validating  product  and  product-component  requirements 

Examples  of  work  products  reviewed  include  the  following:  [pais7.elh2] 

•  Product  requirements 

•  Product-component  requirements 

•  Interface  requirements 

•  Functional  architecture 
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GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institution; 

Review  the  activities,  status,  and  results  of  the  requirements 
development  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 

alize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  requirements 
development  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  requirements  development  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the 
requirements  development  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gpus] 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  requirements  development  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  [gpiwi 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 
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GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  requirements  development 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [gpi25] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  requirements  development  process.  [GP121] 
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TECHNICAL  SOLUTION 

Engineering 


Purpose 


The  purpose  of  Technical  Solution  is  to  design,  develop,  and  implement 
solutions  to  requirements.  Solutions,  designs,  and  implementations 
encompass  products,  product  components,  and  product-related  life- 
cycle  processes  either  singly  or  in  combinations  as  appropriate,  [paibo] 


Introductory  Notes 


The  Technical  Solution  process  area  is  applicable  at  any  level  of  the 
product  architecture  and  to  every  product,  product  component,  product- 
related  life-cycle  process,  and  service.  The  process  area  focuses  on  the 
following:  [pai6o.nioi] 

•  Evaluating  and  selecting  solutions  (sometimes  referred  to  as 
“design  approaches,”  “design  concepts,”  or  “preliminary  designs”) 
that  potentially  satisfy  an  appropriate  set  of  allocated  requirements 

•  Developing  detailed  designs  for  the  selected  solutions  (detailed  in 
the  context  of  containing  all  the  information  needed  to 
manufacture,  code,  or  otherwise  implement  the  design  as  a 
product  or  product  component) 

•  Implementing  the  designs  as  a  product  or  product  component 

Typically,  these  activities  interactively  support  each  other.  Some  level  of 
design,  at  times  fairly  detailed,  may  be  needed  to  select  solutions. 
Product-component  prototypes  may  be  used  as  a  means  of  gaining 
sufficient  knowledge  to  develop  a  technical  data  package  or  a  complete 
set  of  requirements.  [pai6o.nio2] 

Technical  Solution  specific  practices  apply  not  only  to  the  product  and 
product  components  but  also  to  services  and  product-related  life-cycle 
processes.  The  product-related  life-cycle  processes  are  developed  in 
concert  with  the  product  or  product  component.  Such  development  may 
include  selecting  and  adapting  existing  processes  (including  standard 
processes)  for  use  as  well  as  developing  new  processes.  [pai6o.nio3] 

Processes  associated  with  the  Technical  Solution  process  area  receive 
the  product  and  product-component  requirements  from  the 
requirements  management  processes.  The  requirements  management 
processes  place  the  requirements,  which  originate  in  requirements 
development  processes,  under  appropriate  configuration  management 
and  maintain  their  traceability  to  previous  requirements.  [pai6o.nio4] 
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For  a  maintenance  or  sustainment  organization,  the  requirements  in 
need  of  maintenance  actions  or  redesign  may  be  driven  by  user  needs 
or  latent  defects  in  the  product  components.  New  requirements  may 
arise  from  changes  in  the  operating  environment.  Such  requirements 
can  be  uncovered  during  verification  of  the  product(s)  where  actual 
performance  can  be  compared  against  the  specified  performance  and 
unacceptable  degradation  can  be  identified.  Processes  associated  with 
the  Technical  Solution  process  area  should  be  used  to  perform  the 
maintenance  or  sustainment  design  efforts,  [paibo.nios] 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  allocations,  establishing  an  operational 
concept,  and  interface  requirements  definition,  [pawo.rioii 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews  and  verifying  that  the  product  and  product 
components  meet  requirements.  [paibo.rio2] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluation.  [paibo.rio3] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements.  The  specific  practices  in  the 
Requirements  Management  process  area  are  performed  interactively 
with  those  in  the  Technical  Solution  process  area,  [paibo.riov 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  the  organization's  technology. 

[PA160.R105] 


Specific  Goals 


SG  1 

Select  Product-Component  Solutions  [PAieo.iGioi] 

Product  or  product-component  solutions  are  selected  from  alternative 
solutions. 

SG2 

Develop  the  Design  [pai6o.igio2] 

Product  or  product-component  designs  are  developed. 
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SG  3  Implement  the  Product  Design  [pai6o.igio3] 

Product  components,  and  associated  support  documentation,  are 
implemented  from  their  designs. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Select  Product-Component  Solutions  [paigo.igioi] 

SP  1.1-1  Develop  Alternative  Solutions  and  Selection  Criteria 
SP  1.1-2  Develop  Detailed  Alternative  Solutions  and  Selection  Criteria 
SP  1.2-2  Evolve  Operational  Concepts  and  Scenarios 
SP  1 .3-1  Select  Product-Component  Solutions 

SG  2  Develop  the  Design  [PA160.IG102] 

SP  2.1-1  Design  the  Product  or  Product  Component 
SP  2.2-3  Establish  a  Technical  Data  Package 
SP  2.3-1  Establish  Interface  Descriptions 

SP  2.3-3  Design  Interfaces  Using  Criteria 

SP  2.4-3  Perform  Make,  Buy,  or  Reuse  Analyses 

SG  3  Implement  the  Product  Design  [pai6o.igio3] 

SP  3.1-1  Implement  the  Design 

SP  3.2-1  Develop  Product  Support  Documentation 
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GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [clio3.ghoi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clioaglioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Select  Product-Component  Solutions 


Product  or  product-component  solutions  are  selected  from  alternative 
solutions.  [PAi6o.iGioi] 

Alternative  solutions  and  their  relative  merits  are  considered  in  advance 
of  selecting  a  solution.  Key  requirements,  design  issues,  and 
constraints  are  established  for  use  in  alternative  solution  analysis. 
Architectural  features  that  provide  a  foundation  for  product  improvement 
and  evolution  are  considered.  Use  of  commercial  off-the-shelf  (COTS) 
product  components  are  considered  relative  to  cost,  schedule, 
performance,  and  risk.  COTS  alternatives  may  be  used  with  or  without 
modification.  Sometimes  such  items  may  require  modifications  to 
aspects  such  as  interfaces  or  a  customization  of  some  of  the  features  to 
better  achieve  product  requirements,  [paibo.igioi  nioi] 

One  indicator  of  a  good  design  process  is  that  the  design  was  chosen 
after  comparing  and  evaluating  it  against  alternative  solutions. 

Decisions  on  architecture,  custom  development  versus  off  the  shelf, 
and  product-component  modularization  are  typical  of  the  design  choices 
that  are  addressed,  [pai6o.igioi.nio2] 
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Sometimes  the  search  for  solutions  examines  alternative  instances  of 
the  same  requirements  with  no  allocations  needed  to  lower  level 
product  components.  Such  is  the  case  at  the  bottom  of  the  product 
architecture.  There  are  also  cases  where  one  or  more  of  the  solutions 
are  fixed  (e.g.,  a  specific  solution  is  directed  or  available  product 
components,  such  as  COTS,  are  investigated  for  use),  [pai6o.igioi.nio3] 

In  the  general  case,  solutions  are  defined  as  a  set.  That  is,  when 
defining  the  next  layer  of  product  components,  the  solution  for  each  of 
the  product  components  in  the  set  is  established.  The  alternative 
solutions  are  not  only  different  ways  of  addressing  the  same 
requirements,  but  they  also  reflect  a  different  allocation  of  requirements 
among  the  product  components  comprising  the  solution  set.  The 
objective  is  to  optimize  the  set  as  a  whole  and  not  the  individual  pieces. 
There  will  be  significant  interaction  with  processes  associated  with  the 
Requirements  Development  process  area  to  support  the  provisional 
allocations  to  product  components  until  a  solution  set  is  selected  and 
final  allocations  established,  [pai6o.igioi.nio4] 

Product-related  life-cycle  processes  are  among  the  product-component 
solutions  that  are  selected  from  alternative  solutions.  Examples  of  these 
product-related  life-cycle  processes  are  the  manufacturing  and  the 
support  processes,  [pai6o.igioi.nio5] 


SP  1.1-1  Develop  Alternative  Solutions  and  Selection  Criteria 

Develop  alternative  solutions  and  selection  criteria,  [paibo.igioi.spioi] 


In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria  specific  practice. 

Refer  to  the  Allocate  Product-Component  Requirements  specific 
practice  in  the  Requirements  Development  process  area  for  more 
information  about  obtaining  provisional  allocations  of  requirements  to 
solution  alternatives  for  the  product  components,  [pawo.igioi.spioi.rwi] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  establishing  selection  criteria  and  identifying 
alternatives,  [pai6o.igwi.spwi.rio2] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  the  provisional  and  established  allocated 
requirements,  [pai6o.igioi.spwi.rw3] 


362 


Engineering,  Technical  Solution 


CMMI-SW,  vl.1 
Continuous  Representation 


Alternatives  are  based  on  potential  product  architectures  and  span  a 
design  space  of  feasible  solutions.  The  Design  Product  or  Product 
Component  specific  practice  of  the  Develop  the  Design  specific  goal 
contains  more  information  about  developing  potential  product 
architectures  to  incorporate  into  alternative  solutions  for  the  product. 

[PA160.IG101.SP101.N101] 


As  selections  are  made,  the  design  space  may  be  constricted  and  other 
alternatives  examined  until  the  most  promising  (i.e.,  optimal)  solutions 
that  meet  requirements  and  criteria  are  identified.  The  selection  criteria 
identify  the  key  factors  that  provide  a  basis  for  the  selection  of  the 
solution.  These  criteria  should  provide  clear  discrimination  and  an 
indication  of  success  in  arriving  at  a  balanced  solution  across  the  life  of 
the  product.  They  typically  include  measures  of  cost,  schedule, 
performance,  and  risk,  [pai6o.igioi.spioi.nio2] 

The  alternative  solutions  evaluated  frequently  encompass  alternative 
requirement  allocations  to  different  product  components.  These 
alternatives  may  also  be  structured  to  evaluate  the  use  of  COTS 
solutions  in  the  product  architecture.  Processes  associated  with  the 
Requirements  Development  process  area  would  then  be  employed  to 
provide  a  more  complete  and  robust  provisional  allocation  of 
requirements  to  the  alternative  solutions,  [pai6o.igioi.spioi.nio3] 

Selection  of  the  best  solution  establishes  the  requirements  provisionally 
allocated  to  that  solution  as  the  set  of  allocated  requirements.  The 
circumstances  in  which  it  would  not  be  useful  to  examine  alternative 
solutions  are  infrequent  in  new  developments.  However,  developments 
of  precedented  product  components  are  candidates  for  not  examining, 
or  only  minimally  examining,  alternative  solutions,  [pai6o.igioi.spioi.nio4] 

Typical  Work  Products 

1.  Alternative  solutions  [paiso.igioi.spioi.wioi] 

2.  Selection  criteria  [pai6o.igioi.spioi.wio2] 

Subpractices 

1 .  Establish  and  maintain  a  process  or  processes  for  identifying 
solution  alternatives,  selection  criteria,  and  design  issues. 

[PA160.IG101.SP101.SubP101] 
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Selection  criteria  are  influenced  by  a  wide  variety  of  factors  driven  by  the 
requirements  imposed  on  the  project  as  well  as  the  product  life  cycle.  For 
example,  criteria  related  to  mitigating  cost  and  schedule  risks  may  influence  a 
greater  preference  for  COTS  solutions  provided  such  selections  do  not  result  in 
unacceptable  risks  for  the  remaining  product  components  to  be  developed.  When 
using  existing  items,  such  as  COTS,  either  with  or  without  modification,  criteria 
dealing  with  diminishing  sources  of  supply  or  technological  obsolescence  should 
be  examined,  as  well  as  criteria  capturing  the  benefits  of  standardization, 
maintaining  relationships  with  suppliers,  and  so  forth.  The  criteria  used  in 
selections  should  provide  a  balanced  approach  to  costs,  benefits,  and  risks. 

[PA160.IG101.SP101.SubP101.N101] 

2.  Identify  alternative  groupings  of  requirements  that  characterize  sets 
of  solution  alternatives  that  span  the  feasible  design  space. 

[PA160.IG101.SP101.SubP102] 

Effective  employment  of  COTS  alternatives  can  provide  special  challenges. 
Knowledgeable  designers  familiar  with  candidate  COTS  alternatives  may  explore 
architectural  opportunities  to  exploit  potential  COTS  payoffs. 

[PA160.IG101.SP101.SubP102.N101] 

3.  Identify  design  issues  for  each  solution  alternative  in  each  set  of 
alternatives.  [PAi6o.iGioi.spioi.subPio3] 

4.  Characterize  design  issues  and  take  appropriate  action. 

[PA160.IG101.SP101.SubP104] 

Appropriate  action  could  be  to  characterize  the  issues  as  a  risk  for  risk 
management,  adjust  the  solution  alternative  to  preclude  the  issues,  or  reject  the 
solution  alternative  and  replace  it  with  a  different  alternative. 

[PA160.IG101.SP101.SubP104.N101] 

5.  Obtain  a  complete  requirements  allocation  for  each  alternative. 

[PA160.IG101  .SP1 01  .SubP105] 

6.  Document  the  rationale  for  each  alternative  set  of  solutions. 

[PA160.IG101.SP101.SubP106] 


SP  1.1-2  Develop  Detailed  Alternative  Solutions  and  Selection  Criteria 
Develop  detailed  alternative  solutions  and  selection  criteria. 

[PA160.IG101  .SP102] 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Develop 
Alternative  Solutions  and  Selection  Criteria  specific  practice. 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  establishing  criteria  used  in  making  decisions. 

[PA160.IG101.SP102.R101] 
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Detailed  alternative  solutions  are  an  essential  concept  of  the  Technical 
Solution  process  area.  They  provide  more  accurate  and  comprehensive 
information  about  the  solution  than  nondetailed  alternatives.  For 
example,  characterization  of  performance  based  on  design  content 
rather  than  on  simple  estimating  enables  effective  assessment  and 
understanding  of  environment  and  operating  concept  impacts. 
Alternative  solutions  need  to  be  identified  and  analyzed  to  enable  the 
selection  of  a  balanced  solution  across  the  life  of  the  product  in  terms  of 
cost,  schedule,  and  technical  performance.  These  solutions  are  based 
on  proposed  product  architectures  that  address  critical  product 
qualities.  Specific  practices  associated  with  the  Develop  the  Design 
specific  goal  provide  more  information  on  developing  potential  product 
architectures  that  can  be  incorporated  into  alternative  solutions  for  the 

prOdUCt.  [PA160.IG101.SP102.N104] 

Alternative  solutions  span  the  acceptable  range  of  cost,  schedule,  and 
performance.  The  product-component  requirements  are  received  and 
used  along  with  design  issues,  constraints,  and  criteria  to  develop  the 
alternative  solutions.  Selection  criteria  would  typically  address  costs 
(e.g.,  time,  people,  money),  benefits  (e.g.,  performance,  capability, 
effectiveness),  and  risks  (e.g.,  technical,  cost,  schedule). 

Considerations  for  detailed  alternative  solutions  and  selection  criteria 
include  the  following:  [pai6o.igioi.spio2.nio2] 

•  Cost  (development,  procurement,  support,  product  life  cycle) 

•  Technical  performance 

•  Complexity  of  the  product  component  and  product-related  life-cycle 
processes 

•  Robustness  to  product  operating  and  use  conditions,  operating 
modes,  environments,  and  variations  in  product-related  life-cycle 
processes 

•  Product  expansion  and  growth 

•  Technology  limitations 

•  Sensitivity  to  construction  methods  and  materials 

•  Risk 

•  Evolution  of  requirements  and  technology 

•  Disposal 

•  Capabilities  and  limitations  of  end  users  and  operators 
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The  considerations  listed  above  are  a  basic  set;  organizations  should 
develop  screening  criteria  to  narrow  down  the  list  of  alternatives  that  are 
consistent  with  their  business  objectives.  Product  life-cycle  cost,  while 
being  a  desirable  parameter  to  minimize,  may  be  outside  the  control  of 
development  organizations.  A  customer  may  not  be  willing  to  pay  for 
features  that  cost  more  in  the  short  term  but  ultimately  decrease  cost 
over  the  life  of  the  product.  In  such  cases,  customers  should  at  least  be 
advised  of  any  potential  for  reducing  life-cycle  costs.  The  criteria  used 
in  selections  of  final  solutions  should  provide  a  balanced  approach  to 
costs,  benefits,  and  risks,  [pai6o.igioi.spio2.nio3] 

Typical  Work  Products 

1.  Alternative  solution  screening  criteria  [pai6o.igioi.spio2.wio3] 

2.  Evaluations  of  new  technologies  [pai6o.igioi.spio2.wio4] 

3.  Alternative  solutions  [pai6o.igioi.spio2.wioi] 

4.  Selection  criteria  for  final  selection  [pai6o.igioi.spio2.wio2] 

Subpractices 

1 .  Identify  screening  criteria  to  select  a  set  of  alternative  solutions  for 
consideration.  [PAi6o.iGioi.spio2.subPioi] 

2.  Identify  technologies  currently  in  use  and  new  product  technologies 
for  competitive  advantage.  [PAi6o.iGioi.spio2.subPio2] 

Refer  to  the  Organizational  Innovation  and  Deployment  process 
area  for  more  information  about  improving  the  organization's 
technology.  [PAi60.iGi01.spw2.subPi02.Ri0i] 

The  project  should  identify  technologies  applied  to  current  products  and 
processes  and  monitor  the  progress  of  currently  used  technologies  throughout  the 
life  of  the  project.  The  project  should  identify,  select,  evaluate,  and  invest  in  new 
technologies  to  achieve  competitive  advantage.  Alternative  solutions  could  include 
newly  developed  technologies,  but  could  also  include  applying  mature 
technologies  in  different  applications  or  to  maintain  current  methods. 

[PAi60.iGi01.sp102.subPi02.Ni0i] 

3.  Generate  alternative  solutions.  [PAi6o.iGioi.spio2.subPio3] 

4.  Obtain  a  complete  requirements  allocation  for  each  alternative. 

[PA160.IG101.SP102.SubP104] 

5.  Develop  the  criteria  for  selecting  the  best  alternative  solution. 

[PA160.IG101.SP102.SubP105] 
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Criteria  should  be  included  that  address  design  issues  for  the  life  of  the  product, 
such  as  provisions  for  more  easily  inserting  new  technologies  or  the  ability  to 
better  exploit  commercial  products.  Examples  include  criteria  related  to  open 
design  or  open  architecture  concepts  for  the  alternatives  being  evaluated. 

[PA160.IG101.SP102.SubP105.N101] 

6.  Develop  timeline  scenarios  for  product  operation  and  user 
interaction  for  each  alternative  solution.  [PAi6o.iGioi.spio2.subPio6] 


SP  1.2-2  Evolve  Operational  Concepts  and  Scenarios 

Evolve  the  operational  concept,  scenarios,  and  environments  to 
describe  the  conditions,  operating  modes,  and  operating  states 
specific  to  each  product  component,  [pai6o.igwi.spw3] 


Refer  to  the  Establish  Operational  Concepts  and  Scenarios  specific 
practice  of  the  Requirements  Development  process  area  for  information 
on  product-level  influences  and  implications  of  product-component 
operations,  [pai6o.igwi.spw3.rwi] 

Operational  concepts  and  scenarios  are  evolved  to  facilitate  the 
selection  of  product-component  solutions  that,  when  implemented,  will 
satisfy  the  intended  use  of  the  product.  Operational  concepts  and 
scenarios  document  the  interaction  of  the  product  components  with  the 
environment,  users,  and  other  product  components,  regardless  of 
engineering  discipline.  They  should  be  documented  for  operations, 
product  deployment,  delivery,  support  (including  maintenance  and 
sustainment),  training,  and  disposal  and  for  all  modes  and  states. 

[PA160.IG101.SP103.N101] 


The  environments  (operating,  support,  training,  etc.)  also  need  to  be 
evolved.  The  environment  of  any  given  product  component  will  be 
influenced  by  other  product  components  as  well  as  the  external 
environment,  [pai6o.igioi.spio3.nio2] 

Typical  Work  Products 

1 .  Product-component  operational  concepts,  scenarios,  and 
environments  for  all  product-related  life-cycle  processes  (e.g., 
operations,  support,  training,  manufacturing,  deployment,  fielding, 
delivery,  and  disposal)  [pai6o.igioi.spio3.wioi] 

2.  Timeline  analyses  of  product-component  interactions 

[PA160.IG101.SP103.W102] 

3.  Use  cases  [PA160.IG101.SP103.W104] 

Subpractices 

1 .  Evolve  the  operational  concepts  and  scenarios  to  a  degree  of  detail 
appropriate  for  the  product  component.  [PAi6o.iGioi.spio3.subPioi] 
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2.  Evolve  the  operational  environments  for  the  product  components. 

[PA160.IG101.SP103.SubP102] 


The  environments  may  include  thermal,  stress,  and  electromagnetic  and  other 
elements  that  need  to  be  documented.  [PAi6o.iGio1.sp103.subPio2.Nioi] 


SP  1.3-1  Select  Product -Component  Solutions 

Select  the  product-component  solutions  that  best  satisfy  the 
criteria  established,  [pai6o.igioi.spw4] 


Refer  to  the  Allocate  Product-Component  Requirements  and  Identify 
Interface  Requirements  specific  practices  of  the  Requirements 
Development  process  area  for  information  on  establishing  the  allocated 
requirements  for  product  components  and  interface  requirements 
among  product  components,  ipai6o.igioi.spio4.rioi] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  formal  evaluations,  [pai6o.igwi.spio4.rio2] 

Selecting  product  components  that  best  satisfy  the  criteria  establishes 
the  requirement  allocations  to  product  components.  Lower  level 
requirements  are  generated  from  the  selected  alternative  and  used  to 
develop  the  product-component  design.  Interface  requirements  among 
product  components  are  described,  primarily  functionally.  Physical 
interface  descriptions  are  included  in  the  documentation  for  interfaces 
to  items  and  activities  external  to  the  product,  [pai6o.igioi.spio4.nioi] 

The  description  of  the  solutions  and  the  rationale  for  selection  are 
documented.  The  documentation  evolves  throughout  development  as 
solutions  and  detailed  designs  are  developed  and  those  designs  are 
implemented.  Maintaining  a  record  of  rationale  is  critical  to  downstream 
decision  making.  Such  records  keep  downstream  stakeholders  from 
redoing  work  and  provide  insights  to  apply  technology  as  it  becomes 
available  in  applicable  circumstances,  [pai6o.igioi.spio4.nio2] 

Typical  Work  Products 

1 .  Product-component  selection  decisions  and  rationale 

[PA160.IG101.SP104.W101] 

2.  Documented  relationships  between  requirements  and  product 

components  [PA160.IG101.SP104.W102] 

3.  Documented  solutions,  evaluations,  and  rationale  [pai6o.igioi  spio4.wio3] 


368 


Engineering,  Technical  Solution 


CMMI-SW,  vl.1 
Continuous  Representation 

Subpractices 

1 .  Evaluate  each  alternative  solution/set  of  solutions  against  the 
selection  criteria  established  in  the  context  of  the  operating 
concepts,  operating  modes,  and  operating  states. 

[PA160.IG101.SP104.SubP101] 

2.  Based  on  the  evaluation  of  alternatives,  assess  the  adequacy  of 
the  selection  criteria  and  update  these  criteria  as  necessary. 

[PA1 60.IG1 01  .SP1 04.SubP1 02] 

3.  Identify  and  resolve  issues  with  the  alternative  solutions  and 
requirements.  [PAi6o.iGioi.spio4.subPio3] 

4.  Select  the  best  set  of  alternative  solutions  that  satisfy  the 
established  selection  criteria.  [PAi6o.iGioi.spio4.subPio4] 

5.  Establish  the  requirements  associated  with  the  selected  set  of 
alternatives  as  the  set  of  allocated  requirements  to  those  product 
components.  [PAi6o.iGioi.spio4.subPio5] 

6.  Identify  the  product-component  solutions  that  will  be  reused  or 
acquired.  [PAi6o.iGioi.spio4.subPio7] 

Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  products  and  product 

components.  / PA160.IG101.SP104.SubP107.R101 ] 

7.  Establish  and  maintain  the  documentation  of  the  solutions, 
evaluations,  and  rationale.  [PAi6o.iGioi.spio4.subPio6] 


SG  2  Develop  the  Design 


Product  or  product-component  designs  are  developed.  [pai6o.igio2] 

Product  or  product-component  designs  must  provide  the  appropriate 
content  not  only  for  implementation,  but  also  for  other  phases  of  the 
product  life  cycle  such  as  modification,  reprocurement,  maintenance, 
sustainment,  and  installation.  The  design  documentation  provides  a 
reference  to  support  mutual  understanding  of  the  design  by  relevant 
stakeholders  and  supports  future  changes  to  the  design  both  during 
development  and  in  subsequent  phases  of  the  product  life  cycle.  A 
complete  design  description  is  documented  in  a  technical  data  package 
that  includes  a  full  range  of  features  and  parameters  including  form,  fit, 
function,  interface,  manufacturing  process  characteristics,  and  other 
parameters.  Established  organizational  or  project  design  standards 
(e.g.,  checklists,  templates,  object  frameworks)  form  the  basis  for 
achieving  a  high  degree  of  definition  and  completeness  in  design 
documentation,  [pai6o.igio2.nioi] 
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SP  2.1-1  Design  the  Product  or  Product  Component 

Develop  a  design  for  the  product  or  product  component. 

[PA160.IG102.SP101] 


Product  design  consists  of  two  broad  phases  that  may  overlap  in 
execution:  preliminary  and  detailed  design.  Preliminary  design 
establishes  product  capabilities  and  the  product  architecture,  including 
product  partitions,  product-component  identifications,  system  states  and 
modes,  major  intercomponent  interfaces,  and  external  product 
interfaces.  Detailed  design  fully  defines  the  structure  and  capabilities  of 
the  product  components,  [pai6o.igio2.spioi.nioi] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  developing  architecture  requirements. 

[PA160.IG102.SP101.N101.R101] 


Architecture  definition  is  driven  from  a  set  of  architectural  requirements 
developed  during  the  requirements  development  processes.  These 
requirements  express  the  qualities  and  performance  points  that  are 
critical  to  the  success  of  the  product.  The  architecture  defines  structural 
elements  and  coordination  mechanisms  that  either  directly  satisfy 
requirements  or  support  the  achievement  of  the  requirements  as  the 
details  of  the  product  design  are  established.  Architectures  may  include 
standards  and  design  rules  governing  development  of  product 
components  and  their  interfaces  as  well  as  guidance  to  aid  product 
developers.  Specific  practices  in  the  Select  Product-Component 
Solutions  specific  goal  contain  more  information  about  using  product 
architectures  as  a  basis  for  alternative  solutions,  [pai6o.igio2.spioi.nio2] 

Architects  postulate  and  develop  a  model  of  the  product,  making 
judgments  about  allocation  of  requirements  to  product  components 
including  hardware  and  software.  Multiple  architectures,  supporting 
alternative  solutions,  may  be  developed  and  analyzed  to  determine  the 
advantages  and  disadvantages  in  the  context  of  the  architectural 
requirements,  [pai6o.igio2.spioi.nio3] 

Operational  concepts  and  scenarios  are  used  to  generate  use  cases 
and  quality  scenarios  that  are  used  to  refine  the  architecture.  They  are 
also  used  as  a  means  to  evaluate  the  suitability  of  the  architecture  for 
its  intended  purpose  during  architecture  evaluations,  which  are 
conducted  periodically  throughout  product  design.  The  Evolve 
Operational  Concepts  and  Scenarios  specific  practice  gives  more 
information  about  elaborating  operational  concepts  and  scenarios  used 
in  architecture  evaluation,  [pai6o.igio2.spioi.nio4] 

Refer  to  the  Establish  Operational  Concepts  and  Scenarios  specific 
practice  of  the  Requirements  Development  process  area  for  information 
about  developing  operational  concepts  and  scenarios  used  in 
architecture  evaluation,  [pai6o.igio2.spioi.nw4.rioi] 
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For  Software  Engineering 

in  addition  to  tasks  identified  above,  software  architecture  definition  may 

include:  [PA160.IG102.SP101.N104.AMP101] 

•  Establishing  the  structural  relations  of  partitions  and  rules  regarding 
interfaces  between  elements  within  partitions,  and  between  partitions 

•  Identifying  major  internal  interfaces  and  all  external  interfaces  of  software 

•  Identifying  software  product  components 

•  Defining  software  coordination  mechanisms 

•  Establishing  infrastructure  capabilities  and  services 

•  Developing  product-component  templates  or  classes  and  frameworks 

•  Establishing  design  rules  and  authority  for  making  decisions 

•  Defining  a  process/thread  model 

•  Defining  physical  deployment  of  software  to  hardware 

•  Identifying  major  reuse  approaches  and  sources 


During  detailed  design,  the  product  architecture  details  are  finalized, 
product  components  are  completely  defined,  and  interfaces  are  fully 
characterized.  Product-component  designs  may  be  optimized  for  certain 
qualities  or  performance  characteristics.  Designers  may  evaluate  the 
use  of  legacy  or  COTS  products  for  the  product  components.  As  the 
design  matures,  the  requirements  assigned  to  lower  level  product 
components  are  tracked  to  ensure  those  requirements  are  satisfied. 

[PA160.IG102.SP101.N105] 


Refer  to  the  Requirements  Management  process  area  for  more 
information  about  tracking  requirements  for  product  components. 

[PA160.IG102.SP1 01.  N105.R1 01] 

For  Software  Engineering 

Detailed  design  is  focused  on  software  product-component  development. 
The  internal  structure  of  product  components  is  defined,  data  schema  are 
generated,  algorithms  are  developed,  and  heuristics  are  established  to 
provide  product-component  capabilities  that  satisfy  allocated  requirements. 

[PA160.IG102.SP101.N105.AMP101] 


Typical  Work  Products 

1.  Product  architecture  [pai6o.igio2.spioi.wioi] 

2.  Product-component  designs  [PAi60.iGi02.sp101.w102] 

Subpractices 

1 .  Establish  and  maintain  criteria  against  which  the  design  can  be 
evaluated.  [PAi6o.iGio2.spioi.subPioi] 
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Examples  of  attributes,  in  addition  to  expected  performance,  for  which  design 
criteria  can  be  established,  include  the  following:  [PAieo.iGio2.sp101.subPio1.Nioi] 

•  Modular 

•  Clear 

•  Simple 

•  Maintainable 

•  Verifiable 

•  Portable 

•  Reliable 

•  Accurate 

•  Secure 

•  Scalable 

•  Usable 


2.  Identify,  develop,  or  acquire  the  design  methods  appropriate  for  the 

prOdUCt.  [PA160.IG102.SP101.SubP102] 

Effective  design  methods  can  embody  a  wide  range  of  activities,  tools,  and 
descriptive  techniques.  Whether  a  given  method  is  effective  or  not  depends  on  the 
situation.  Two  companies  may  have  very  effective  design  methods  for  products  in 
which  they  specialize,  but  these  methods  may  not  be  effective  in  cooperative 
ventures.  Highly  sophisticated  methods  are  not  necessarily  effective  in  the  hands 
of  designers  that  have  not  been  trained  in  the  use  of  the  methods. 

[PAi60.iGi02.sp101.subPi02.Ni0i] 


Whether  or  not  a  method  is  effective  also  depends  on  how  much  assistance  it 
provides  the  designer,  and  the  cost  effectiveness  of  that  assistance.  For  example, 
a  multiyear  prototyping  effort  may  not  be  appropriate  for  a  simple  product 
component  but  might  be  the  right  thing  to  do  for  an  unprecedented,  expensive, 
and  complex  product  development.  Rapid  prototyping  techniques,  however,  may 
be  highly  effective  for  many  product  components.  Methods  that  use  tools  to 
ensure  that  a  design  will  encompass  all  the  necessary  attributes  needed  to 
implement  the  product-component  design  can  be  very  effective.  For  example,  a 
design  tool  that  “knows”  the  capabilities  of  the  manufacturing  processes  can  allow 
the  variability  of  the  manufacturing  process  to  be  accounted  for  in  the  design 
tolerances.  [PAi60.iGio2.sp1o1.subPio2.Nio2] 
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Examples  of  techniques  and  methods  that  facilitate  effective  design  include  the 
following:  [PAi60.iGi02.sp101.subPi02.Ni03] 

•  Prototypes 

•  Structural  models 

•  Object-oriented  design 

•  Essential  systems  analysis 

•  Entity  relationship  models 

•  Design  reuse 

•  Design  patterns 

3.  Ensure  that  the  design  adheres  to  applicable  design  standards  and 
criteria.  [PAi6o.iGio2.spioi.subPio3] 

Examples  of  design  standards  include  the  following  (some  or  all  of  these 
standards  may  be  design  criteria,  particularly  in  circumstances  where  the 
standards  have  not  been  established):  [PAi60.iGi02.sp101.subPi03.Ni0i] 

•  Operator  interface  standards 

•  Safety  standards 

•  Production  constraints 

•  Design  tolerances 

•  Parts  standards  (e.g.,  production  scrap  and  waste) 

4.  Ensure  that  the  design  adheres  to  allocated  requirements. 

[PA160.IG102.SP101.SubP104] 

Identified  COTS  product  components  must  be  taken  into  account.  For  example, 
putting  existing  product  components  into  the  product  architecture  might  modify  the 
requirements  and  the  requirements  allocation.  [PAi60.iGi02.sp101.subPi04.Ni0i] 

5.  Document  the  design,  [pai6o.igio2.spi 01  .subPi 05] 


SP  2.2-3  Establish  a  Technical  Data  Package 

Establish  and  maintain  a  technical  data  package,  ipai6o.igio2.spw3] 


A  technical  data  package  provides  the  developer  with  a  comprehensive 
description  of  the  product  or  product  component  as  it  is  developed. 
Such  a  package  also  provides  procurement  flexibility  in  a  variety  of 
circumstances  such  as  performance-based  contracting  or  build  to  print. 

[PA160.IG102.SP103.N102] 
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The  design  is  recorded  in  a  technical  data  package  that  is  created 
during  preliminary  design  to  document  the  architecture  definition.  This 
technical  data  package  is  maintained  throughout  the  life  of  the  product 
to  record  essential  details  of  the  product  design.  The  technical  data 
package  provides  the  description  of  a  product  or  product  component 
(including  product-related  life-cycle  processes  if  not  handled  as 
separate  product  components)  that  supports  an  acquisition  strategy,  or 
the  implementation,  production,  engineering,  and  logistics  support 
phases  of  the  product  life  cycle.  The  description  includes  the  definition 
of  the  required  design  configuration  and  procedures  to  ensure 
adequacy  of  product  or  product-component  performance.  It  includes  all 
applicable  technical  data  such  as  drawings,  associated  lists, 
specifications,  design  descriptions,  design  databases,  standards, 
performance  requirements,  quality  assurance  provisions,  and 
packaging  details.  The  technical  data  package  includes  a  description  of 
the  selected  alternative  solution  that  was  chosen  for  implementation. 

[PA160.IG102.SP103.N106] 


A  technical  data  package  should  include  the  following  if  such 
information  is  appropriate  for  the  type  of  product  and  product 
component  (for  example,  material  and  manufacturing  requirements  may 
not  be  useful  for  product  components  associated  with  software  services 
or  processes):  [pai6o.igio2.spio3.nio3] 

•  Product  architecture  description 

•  Allocated  requirements 

•  Product-component  descriptions 

•  Product-related  life-cycle  process  descriptions,  if  not  described  as 
separate  product  components 

•  Key  product  characteristics 

•  Required  physical  characteristics  and  constraints 

•  Interface  requirements 

•  Materials  requirements  (bills  of  material  and  material 
characteristics) 

•  Fabrication  and  manufacturing  requirements  (for  both  the  original 
equipment  manufacturer  and  field  support) 

•  The  verification  criteria  used  to  ensure  that  requirements  have 
been  achieved 

•  Conditions  of  use  (environments)  and  operating/usage  scenarios, 
modes  and  states  for  operations,  support,  training,  manufacturing, 
disposal,  and  verifications  throughout  the  life  of  the  product 

•  Rationale  for  decisions  and  characteristics  (requirements, 
requirement  allocations,  and  design  choices) 


374 


Engineering,  Technical  Solution 


CMMI-SW,  vl.1 
Continuous  Representation 

Because  design  descriptions  can  involve  a  very  large  amount  of  data 
and  be  crucial  to  successful  product-component  development,  it  is 
advisable  to  establish  criteria  for  organizing  the  data  and  for  selecting 
the  data  content.  It  is  particularly  useful  to  use  the  product  architecture 
as  a  means  of  organizing  this  data  and  abstracting  views  that  are  clear 
and  relevant  to  an  issue  or  feature  of  interest.  These  views  include  the 

following:  [PAI6O.IGIO2.SPIO3.NIO4] 

•  Customers 

•  Requirements 

•  The  environment 

•  Functional 

•  Logical 

•  Security 

•  Data 

•  States/modes 

•  Construction 

•  Management 

These  views  are  documented  in  the  technical  data  package. 

[PA160.IG102.SP103.N105] 

Typical  Work  Products 

1.  Technical  data  package  [PAi60.iGi02.sp103.w10i] 

Subpractices 

1 .  Determine  the  number  of  levels  of  design  and  the  appropriate  level 
of  documentation  for  each  design  level.  [PAieo.iGio2.spio3.subPioi] 

Determining  the  number  of  levels  of  product  components  (e.g.,  subsystem, 
hardware  configuration  item,  circuit  board,  computer  software  configuration  item 
[CSCI],  computer  software  product  component,  computer  software  unit)  that 
require  documentation  and  requirements  traceability  is  important  to  manage 
documentation  costs  and  to  support  integration  and  verification  plans. 

[PA160.IG102.SP103.SubP101.N101] 

2.  Base  detailed  design  descriptions  on  the  allocated  product- 
component  requirements,  architecture,  and  higher  level  designs. 

[PA160.IG102.SP103.SubP102] 

3.  Document  the  design  in  the  technical  data  package. 

[PA160.IG102.SP103.SubP103] 

4.  Document  the  rationale  for  key  (i.e.,  significant  effect  on  cost, 
schedule,  or  technical  performance)  decisions  made  or  defined. 

[PA160.IG102.SP103.SubP104] 
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5.  Revise  the  technical  data  package  as  necessary. 

[PA160.IG102.SP103.SubP105] 


SP  2.3-1  Establish  Interface  Descriptions 

Establish  and  maintain  the  solution  for  product-component 
interfaces.  [pai6o.igio2.spio4] 

In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Design  Interfaces  Using  Criteria  specific  practice. 

The  product-component  interface  description  covers  interfaces  between 
the  following:  [pai6o.igio2.spio4.nioi] 

•  Product  components  and  product  components 

•  Lower  level  product  components  and  higher  level  product 
components 

•  Product  components  and  product-related  life-cycle  processes 

•  Product  components  and  external  items 

Typical  Work  Products 

1.  Interface  design  [pai6o.igio2.spio4.wioi] 

2.  Interface  design  documents  [pai6o.igio2.spio4.wio2] 

Subpractices 

1 .  Identify  and  document  interfaces  associated  with  other  product 
components.  [PAi6o.iGio2.spio4.subPioi] 

2.  Identify  interfaces  associated  with  external  items. 

[PA160.IG102.SP104.SubP102] 

3.  Identify  interfaces  between  product  components  and  the  product- 
related  life-cycle  processes.  [PAi6o.iGio2.spio4.subPio3] 

For  example,  such  interfaces  could  include  those  between  a  product  component 
to  be  fabricated  and  the  jigs  and  fixtures  used  to  enable  that  fabrication  during  the 
manufacturing  process.  [PAi60.iGi02.sp104.subPi03.Ni0i] 

4.  Ensure  that  the  solution  includes  the  interface  requirements 
developed  in  the  requirements  development  processes. 

[PA160.IG102.SP104.SubP104] 

Refer  to  the  Identify  Interface  Requirements  specific  practice  in  the 
Requirements  Development  process  area  for  more  information 
about  identifying  product  and  product-component  interface 
requirements.  [PAi60.iGi02.sp104.subPi04.Ri0i] 
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SP  2.3-3  Design  Interfaces  Using  Criteria 

Design  comprehensive  product-component  interfaces  in  terms  of 
established  and  maintained  criteria.  ipai6o.igio2.spios] 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Establish 
Interface  Descriptions  specific  practice. 


Interface  designs  include  the  following:  [pai6o.igio2.spio5.nioi] 

•  Origination 

•  Destination 

•  Stimulus  and  data  characteristics  for  software 

•  Electrical,  mechanical,  and  functional  characteristics  for  hardware 

The  criteria  for  interfaces  frequently  reflect  a  comprehensive  list  of 
critical  parameters  that  must  be  defined,  or  at  least  investigated,  to 
ascertain  their  applicability.  These  parameters  are  often  peculiar  to  a 
given  type  of  product  (e.g.,  software,  mechanical,  electrical)  and  are 
often  associated  with  safety,  security,  durability,  and  mission-critical 
characteristics,  [pai6o.igio2.spios.nio2] 

Typical  Work  Products 

1.  Interface  design  specifications  [pai6o.igio2.spio5.wioi] 

2.  Interface  control  documents  [PAi60.iGi02.sp105.w102] 

3.  Interface  specification  criteria  [pai6o.igio2.spio5.wio3] 

4.  Rationale  for  selected  interface  design  [pai6o.igio2.spio5.wio4] 

Subpractices 

1 .  Define  interface  criteria.  [PAi6o.iGio2.spio5.subPioi] 

These  criteria  can  be  a  part  of  the  organizational  process  assets. 

[PA160.IG102.SP105.SubP101.N101] 

Refer  to  the  Organizational  Process  Definition  process  area  for 
more  information  about  establishing  and  maintaining  organizational 
process  assets.  [PAi60.iGi02.sp105.subPi01.Ni01.Ri0i] 

2.  Apply  the  criteria  to  the  interface  design  alternatives. 

[PA160.IG102.SP105.SubP102] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for 
more  information  about  identifying  criteria  and  selecting 
alternatives  based  on  those  criteria.  [PAi60.iGi02.sp105.subPi02.Ri0i] 

3.  Document  the  selected  interface  designs  and  the  rationale  for  the 

selection.  [PA160.IG102.SP105.SubP103] 
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SP  2.4-3  Perform  Make,  Buy,  or  Reuse  Analyses 

Evaluate  whether  the  product  components  should  be  developed, 
purchased,  or  reused  based  on  established  criteria,  [pai6o.igw2.spw6] 


The  determination  of  what  products  or  product  components  will  be 
acquired  is  frequently  referred  to  as  a  “make-or-buy  analysis.”  It  is 
based  on  an  analysis  of  the  needs  of  the  project.  This  make-or-buy 
analysis  begins  early  in  the  project  during  the  first  iteration  of  design, 
continues  during  the  design  process,  and  is  completed  with  the  decision 
to  develop,  acquire,  or  reuse  the  product,  [pai6o.igio2.spio6.nio3] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  determining  the  product  and  product-component 
requirements,  t pai6o.igw2.spw6.nw3.rwi ; 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements,  [pai6o.igw2.spw6.nw3.rw2] 

Factors  affecting  the  make-or-buy  decision  include  the  following: 

[PA160.IG102.SP106.N104] 

•  Functions  the  products  or  services  will  provide  and  how  these 
functions  will  fit  into  the  project 

•  Available  project  resources  and  skills 

•  Costs  of  acquiring  versus  developing  internally 

•  Critical  delivery  and  integration  dates 

•  Strategic  business  alliances,  including  high-level  business 
requirements 

•  Market  research  of  available  products,  including  COTS  products 

•  Functionality  and  quality  of  available  products 

•  Skills  and  capabilities  of  potential  suppliers 

•  Impact  on  core  competencies 

•  Licenses,  warranties,  responsibilities,  and  limitations  associated 
with  products  being  acquired 

•  Product  availability 

•  Proprietary  issues 

•  Risk  reduction 

Many  of  these  factors  are  addressed  by  the  project,  [pai6o.igio2.spio6.nio5] 

The  make-or-buy  decision  can  be  conducted  using  a  formal  evaluation 
approach.  [PA160.IG102.SP106.N106] 
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Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  defining  criteria  and  alternatives  and  performing 
formal  evaluations.  [pai6o.igio2.spio6.nio6.rioij 

As  technology  evolves,  so  does  the  rationale  for  choosing  to  develop  or 
purchase  a  product  component.  While  complex  development  efforts 
may  favor  purchasing  an  off-the-shelf  product  component,  advances  in 
productivity  and  tools  may  provide  an  opposing  rationale.  Off-the-shelf 
products  may  have  incomplete  or  inaccurate  documentation  and  may  or 
may  not  be  supported  in  the  future,  [pai6o.igio2.spio6.nioi] 

Once  the  decision  is  made  to  purchase  an  off-the-shelf  product 
component,  the  requirements  are  used  to  establish  a  supplier 
agreement.  There  are  times  when  “off  the  shelf”  refers  to  an  existing 
item  that  may  not  be  readily  available  in  the  marketplace.  For  example, 
some  types  of  aircraft  and  engines  are  not  truly  “off  the  shelf”  but  can 
be  readily  procured.  In  some  cases  the  use  of  such  non-developed 
items  is  in  situations  where  the  specifics  of  the  performance  and  other 
product  characteristics  expected  need  to  be  within  the  limits  specified. 

In  these  cases,  the  requirements  and  acceptance  criteria  may  need  to 
be  included  in  the  supplier  agreement  and  managed.  In  other  cases,  the 
off-the-shelf  product  is  literally  off  the  shelf  (word  processing  software, 
for  example)  and  there  is  no  agreement  with  the  supplier  that  needs  to 
be  managed,  [pai6o.igio2.spio6.nio2] 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  how  to  address  the  acquisition  of  the  product 
components  that  will  be  purchased,  [pai6o.igw2.spio6.nio2.rwi] 

Typical  Work  Products 

1 .  Criteria  for  design  and  product-component  reuse  [pai6o.igio2.spio6.wioi] 

2.  Make-or-buy  analyses  [pai6o.igio2.spio6.wio2] 

3.  Guidelines  for  choosing  COTS  product  components 

[PA160.IG102.SP106.W103] 

Subpractices 

1 .  Develop  criteria  for  the  reuse  of  product-component  designs. 

[PA160.IG102.SP106.SubP102] 

2.  Analyze  designs  to  determine  if  product  components  should  be 
developed,  reused,  or  purchased.  [PAi6o.iGio2.spioe.subPio3] 

3.  When  purchased  or  non-developmental  (COTS,  government  off  the 
shelf,  and  reuse)  items  are  selected,  plan  for  their  maintenance. 

[PA160.IG102.SP1 06. SubPI  01] 
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For  Software  Engineering 

Consider  how  the  compatibility  of  future  releases  of  an 
operating  system  and  a  database  manager  will  be  handled. 

[PA160.IG102.SP106.SubP101.AMP101] 


SG  3  Implement  the  Product  Design 


Product  components,  and  associated  support  documentation,  are 
implemented  from  their  designs.  [pai6o.igio3] 

Product  components  are  implemented  from  the  designs  established  by 
the  specific  practices  in  the  Develop  the  Design  specific  goal.  The 
implementation  usually  includes  unit  testing  of  the  product  components 
before  sending  them  to  product  integration  and  development  of  end- 
user  documentation,  [pai6o.igio3.moi] 


SP  3.1-1  Implement  the  Design 

Implement  the  designs  of  the  product  components.  [pai6o.igio3.spioi] 

For  Software  Engineering 

Software  code  is  a  typical  software  product  component. 

[PA160.IG103.SP101.AMP101] 


Once  the  design  has  been  completed,  it  is  implemented  as  a  product 
component.  The  characteristics  of  that  implementation  depend  on  the 
type  of  product  component,  [pai6o.igio3.spioi.nioi] 

Design  implementation  at  the  top  level  of  the  product  hierarchy  involves 
the  specification  of  each  of  the  product  components  at  the  next  level  of 
the  product  hierarchy.  This  activity  includes  the  allocation,  refinement, 
and  verification  of  each  product  component.  It  also  involves  the 
coordination  between  the  various  product-component  development 

effOrtS.  [PA160.IG103.SP101.N103] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  the  allocation  and  refinement  of  requirements. 

[PA160.IG103.SP101.N103.R101] 


Refer  to  the  Product  Integration  process  area  for  more  information 
about  the  management  of  interfaces  and  the  integration  of  products  and 
product  components,  i pai6o.igio3.spioi.nio3.rio2 i 
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Example  characteristics  of  this  implementation  are  as  follows:  [pai6o.igio3.spioi.nio2] 

•  Software  is  coded. 

•  Data  is  documented. 

•  Services  are  documented. 

•  Electrical  and  mechanical  parts  are  fabricated. 

•  Product-unique  manufacturing  processes  are  put  into  operation. 

•  Processes  are  documented. 

•  Facilities  are  constructed. 

•  Materials  are  produced  (e.g.,  a  product-unique  material  could  be  a  petroleum,  oil, 
or  lubricant,  or  a  new  alloy). 


Typical  Work  Products 

1.  Implemented  design  [pai6o.igio3.spioi.wioi] 

Subpractices 

1 .  Use  effective  methods  to  implement  the  product  components. 

[PA160.IG103.SP101.SubP101] 

For  Software  Engineering 

Examples  of  software  coding  methods  include  the  following: 

[PA160.IG103.SP1 01  .SubPI 01  .AMP101] 

•  Structured  programming 

•  Object-oriented  programming 

•  Automatic  code  generation 

•  Software  code  reuse 

•  Use  of  applicable  design  patterns 

2.  Adhere  to  applicable  standards  and  criteria.  [PAieo.iGio3.spioi.subPio2] 

For  Software  Engineering 

Examples  of  software  coding  standards  include  the  following: 

[PA160.IG1 03.SP1 01  .SubPI  02.AMP101] 

•  Language  standards 

•  Naming  conventions  for  variables 

•  Acceptable  language  structures 

•  Structure  and  hierarchy  of  software  product  components 

•  Format  of  code  and  comments 
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For  Software  Engineering 

Examples  of  software  coding  criteria  include  the  following: 

[PA160.IG103.SP101.SubP102.AMP102] 

•  Modularity 

•  Clarity 

•  Simplicity 

•  Structured  (e.g.,  no  GOTOs,  one  entrance ,  and  one  exit) 

•  Maintainability 

3.  Conduct  peer  reviews  of  the  selected  product  components. 

[PA160.IG103.SP101.SubP103] 

Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews.  [PAi60.iGi03.sp101.subPi03.Ri0i] 

4.  Perform  unit  testing  of  the  product  component  as  appropriate. 

[PA160.IG103.SP101.SubP104] 

Note  that  unit  testing  is  not  limited  to  software.  Unit  testing  involves  the  testing  of 
individual  hardware  or  software  units  or  groups  of  related  items  prior  to  integration 
of  those  items.  [PAi60.iGio3.sp101.subPio4.Nioi] 

Refer  to  the  Verification  process  area  for  more  information  about 
verification  methods  and  procedures  and  about  verifying  work 
products  against  their  specified  requirements. 

[PA160.IG103.SP101.SubP104.N101.R101] 

For  Software  Engineering 

Examples  of  unit  testing  methods  include  the  following: 

[PA160.IG103.SP101.SubP104.N101.AMP101] 

•  Statement  coverage  testing 

•  Branch  coverage  testing 

•  Predicate  coverage  testing 

•  Path  coverage  testing 

•  Boundary  value  testing 

•  Special  value  testing 

5.  Revise  the  product  component  as  necessary.  [PAi6o.iGio3.spioi.subPio5] 

An  example  of  when  the  product  component  may  need  to  be  revised  is  when 
problems  surface  during  implementation  that  could  not  be  foreseen  during  design. 

[PA160.IG103.SP101.SubP105.N101] 
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SP  3.2-1  Develop  Product  Support  Documentation 

Develop  and  maintain  the  end-use  documentation,  ipai6o.igio3.spi 02] 

This  specific  practice  develops  and  maintains  the  documentation  that 
will  be  used  to  install,  operate,  and  maintain  the  product. 

[PA160.IG103.SP102.N101] 

Typical  Work  Products 

1 .  End-user  training  materials  [PAi60.iGi03.sp102.w10i] 

2.  User's  manual  [PAi60.iGi03.sp102.w102] 

3.  Operator's  manual  [PAi60.iGi03.sp102.w103] 

4.  Maintenance  manual  [PAi60.iGi03.sp102.w104] 

5.  Online  help  [pai6o.igio3.spio2.wios] 

Subpractices 

1 .  Review  the  requirements,  design,  product,  and  test  results  to 
ensure  that  issues  affecting  the  installation,  operation,  and 
maintenance  documentation  are  identified  and  resolved. 

[PA160.IG103.SP1 02. SubPI  01] 

2.  Use  effective  methods  to  develop  the  installation,  operation,  and 
maintenance  documentation.  [PAi6o.iGio3.spio2.subPio2] 

3.  Adhere  to  the  applicable  documentation  standards. 

[PA160.IG103.SP102.SubP103] 

Examples  of  documentation  standards  include  the  following: 

[PA160.IG103.SP102.SubP103.N101] 

•  Compatibility  with  designated  word  processors 

•  Acceptable  fonts 

•  Numbering  of  pages,  sections,  and  paragraphs 

•  Consistency  with  a  designated  style  manual 

•  Use  of  abbreviations 

•  Security  classification  markings 

•  Internationalization  requirements 

4.  Develop  preliminary  versions  of  the  installation,  operation,  and 
maintenance  documentation  in  early  phases  of  the  project  life  cycle 
for  review  by  the  relevant  stakeholders.  [PAieo.iGio3.spio2.subPio4] 

5.  Conduct  peer  reviews  of  the  installation,  operation,  and 
maintenance  documentation.  [PAi6o.iGio3.spio2.subPios] 
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Refer  to  the  Verification  process  area  for  more  information  about 
conducting  peer  reviews,  i PAi60.iGi03.sp102.subPi05.Ri01 j 

6.  Revise  the  installation,  operation,  and  maintenance  documentation 
as  necessary.  [PAi6o.iGio3.spio2.subPio6] 

Examples  of  when  documentation  may  need  to  be  revised  include  when  the 
following  events  occur:  [PAi60.iGi03.sp102.subPi06.Nim] 

•  Requirements  change 

•  Design  changes  are  made 

•  Product  changes  are  made 

•  Documentation  errors  are  identified 

•  Workaround  fixes  are  identified 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  technical  solution  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area.  [GP102] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  technical  solution  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  addressing  the 
iterative  cycle  in  which  product-component  solutions  are  selected, 
product  and  product-component  designs  are  developed,  and  the 
product-component  designs  are  implemented,  [paibo.elioi] 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  technical 
solution  process.  [gpio4] 

Elaboration: 

Typically,  this  plan  for  performing  the  technical  solution  process  is  a 
part  of  the  project  plan  as  described  in  the  Project  Planning  process 
area.  [pai6o.elio2] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  technical  solution 
process,  developing  the  work  products,  and  providing  the  services 
of  the  process,  [gpiosj 


Elaboration: 

Special  facilities  may  be  required  for  developing,  designing,  and 
implementing  solutions  to  requirements.  When  necessary,  the  facilities 
required  for  the  activities  in  the  Technical  Solution  process  area  are 
developed  or  purchased.  [pai6o.elih] 

Examples  of  other  resources  provided  include  the  following  tools:  [pai6o.eho4] 

•  Design  specification  tools 

•  Simulators  and  modeling  tools 

•  Prototyping  tools 

•  Scenario  definition  and  management  tools 

•  Requirements  tracking  tools 

•  Interactive  documentation  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
technical  solution  process,  [gpiosi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  technical  solution 
process  as  needed.  [gpio7] 
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Elaboration: 

Examples  of  training  topics  include  the  following:  [paibo.elios] 

•  Application  domain  of  the  product  and  product  components 

•  Design  methods 

•  Interface  design 

•  Unit  testing  techniques 

•  Standards  (e.g.,  product,  safety,  human  factors,  environmental) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  technical  solution  process 
under  appropriate  levels  of  configuration  management,  igpioq] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  ipai6o.elio6] 

•  Product,  product  component,  process,  service,  and  interface  designs 

•  Technical  data  packages 

•  Interface  design  documents 

•  Criteria  for  design  and  product-component  reuse 

•  Implemented  designs  (e.g.,  software  code,  fabricated  product  components) 

•  User,  installation,  operation,  and  maintenance  documentation 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  technical 
solution  process  as  planned,  [g pi24] 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process.  [pai6o.elh3] 
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Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai6o.elh4] 

•  Developing  alternative  solutions  and  selection  criteria 

•  Evolving  operational  concept  and  scenarios 

•  Obtaining  approval  on  external  interface  specifications  and  design  descriptions 

•  Developing  the  technical  data  package 

•  Assessing  the  make,  buy,  or  reuse  alternatives  for  product  components 

•  Implementing  the  design 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  technical  solution  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action,  [gphoj 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA160.EL108] 

•  Cost,  schedule,  and  effort  expended  for  rework 

•  Percentage  of  requirements  addressed  in  the  product  or  product-component 
design 

•  Size  and  complexity  of  the  product,  product  components,  interfaces,  and 
documentation 

•  Defect  density  of  technical  solutions  work  products 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  technical  solution  process 
against  its  process  description,  standards,  and  procedures,  and 
address  noncompliance.  [GPinj 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai6o.eliio] 

•  Selecting  product-component  solutions 

•  Developing  product  and  product-component  designs 

•  Implementing  product-component  designs 
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Examples  of  work  products  reviewed  include  the  following:  [pai6o.elh2] 

•  Technical  data  packages 

•  Product,  product-component,  and  interface  designs 

•  Implemented  designs  (e.g.,  software  code,  fabricated  product  components) 

•  User,  installation,  operation,  and  maintenance  documentation 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  technical  solution 
process  with  higher  level  management  and  resolve  issues.  igpu2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  technical 
solution  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  technical  solution  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[GP117] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  technical 
solution  process  that  address  quality  and  process  performance 
based  on  customer  needs  and  business  objectives,  [gphs] 
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GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  technical  solution  process  to  achieve 
the  established  quantitative  quality  and  process-performance 
objectives,  [gph9] 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  technical  solution  process 
in  fulfilling  the  relevant  business  objectives  of  the  organization. 

[GP12S] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  technical  solution  process.  [GP1211 
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PRODUCT  INTEGRATION 

Engineering 


Purpose 


The  purpose  of  Product  Integration  is  to  assemble  the  product  from  the 
product  components,  ensure  that  the  product,  as  integrated,  functions 
properly,  and  deliver  the  product,  [paw] 


Introductory  Notes 


This  process  area  addresses  the  integration  of  product  components  into 
more  complex  product  components  or  into  complete  products.  The  term 
“integration”  is  used  in  this  sense  throughout  this  process  area  and  is 
not  to  be  confused  with  integration  of  people  or  activities  that  may  be 
described  elsewhere  in  the  model,  [pamz.nioi] 

The  scope  of  this  process  area  is  to  achieve  complete  product 
integration  through  progressive  assembly  of  product  components,  in 
one  stage  or  in  incremental  stages,  according  to  a  defined  integration 
sequence  and  procedures,  [paw.nkk] 

A  critical  aspect  of  product  integration  is  the  management  of  internal 
and  external  interfaces  of  the  products  and  product  components  to 
ensure  compatibility  among  the  interfaces.  Attention  should  be  paid  to 
interface  management  throughout  the  project.  [pai47.nio3] 

Product  integration  is  more  than  just  a  one-time  assembly  of  the 
product  components  at  the  conclusion  of  design  and  fabrication. 

Product  integration  can  be  conducted  incrementally,  using  an  iterative 
process  of  assembling  product  components,  evaluating  them,  and  then 
assembling  more  product  components.  This  process  may  begin  with 
analysis  and  simulations  (e.g.,  threads,  rapid  prototypes,  virtual 
prototypes,  and  physical  prototypes)  and  steadily  progress  through 
increasingly  more  realistic  incremental  functionality  until  the  final 
product  is  achieved.  In  each  successive  build,  prototypes  (virtual,  rapid, 
or  physical)  are  constructed,  evaluated,  improved,  and  reconstructed 
based  upon  knowledge  gained  in  the  evaluation  process.  The  degree  of 
virtual  vs.  physical  prototyping  required  depends  on  the  functionality  of 
the  design  tools,  the  complexity  of  the  product,  and  its  associated  risk. 
There  is  a  high  probability  that  the  product,  integrated  in  this  manner, 
will  pass  product  verification  and  validation.  For  some  products,  the  last 
integration  phase  will  occur  when  the  product  is  deployed  at  its  intended 
operational  site.  [pam7.nio4] 
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Refer  to  the  Requirements  Development  process  area  for  more 
information  about  identifying  interface  requirements.  [pau7.rioii 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
defining  the  interfaces  and  the  integration  environment  (when  the 
integration  environment  needs  to  be  developed).  [PA147.R1021 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  the  interfaces,  the  integration  environment,  and  the 
progressively  assembled  product  components.  ipau7.rio3i 

Refer  to  the  Validation  process  area  for  more  information  about 
performing  validation  of  the  product  components  and  the  integrated 

product.  [PA147.R104] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  risks  and  the  use  of  prototypes  in  risk  mitigation  for  both 
interface  compatibility  and  product-component  integration.  ipau7.rios] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  for  selecting  the 
appropriate  integration  sequence  and  procedures  and  for  deciding 
whether  the  integration  environment  should  be  acquired  or  developed. 

[PA147.R106] 


Refer  to  the  Configuration  Management  process  area  for  more 
information  about  managing  changes  to  interface  definitions  and  about 
the  distribution  of  information.  ipau7.rio7] 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  acquiring  product  components  or  parts  of  the 
integration  environment.  [pau7.rio8] 


Specific  Goals 


SG  1 

Prepare  for  Product  Integration  [paw.igioii 

Preparation  for  product  integration  is  conducted. 

SG2 

Ensure  Interface  Compatibility  [PA1471G102] 

The  product-component  interfaces,  both  internal  and  external,  are  compatible. 
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SG  3  Assemble  Product  Components  and  Deliver  the  Product  [pai47.igio3] 

Verified  product  components  are  assembled  and  the  integrated,  verified,  and 
validated  product  is  delivered. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 


The  process  is  institutionalized  as  a  managed  process. 


GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 


The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [chosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Prepare  for  Product  Integration  [paw.igioii 

SP  1.1-1  Determine  Integration  Sequence 

SP  1.2-2  Establish  the  Product  Integration  Environment 

SP  1.3-3  Establish  Product  Integration  Procedures  and  Criteria 

SG  2  Ensure  Interface  Compatibility  [paw.igkk] 

SP  2.1-1  Review  Interface  Descriptions  for  Completeness 

SP  2.2-1  Manage  Interfaces 

SG  3  Assemble  Product  Components  and  Deliver  the  Product  [paw.igkm] 

SP  3.1-1  Confirm  Readiness  of  Product  Components  for  Integration 

SP  3.2-1  Assemble  Product  Components 

SP  3.3-1  Evaluate  Assembled  Product  Components 

SP  3.4-1  Package  and  Deliver  the  Product  or  Product  Component 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 
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GG  2  Institutionalize  a 
GP  2.1 
GP  2.2 
GP  2.3 
GP  2.4 
GP  2.5 
GP  2.6 
GP  2.7 
GP  2.8 
GP  2.9 
GP  2.10 


Managed  Process  [clio3.ghoi] 

Establish  an  Organizational  Policy 

Plan  the  Process 

Provide  Resources 

Assign  Responsibility 

Train  People 

Manage  Configurations 

Identify  and  Involve  Relevant  Stakeholders 

Monitor  and  Control  the  Process 

Objectively  Evaluate  Adherence 

Review  Status  with  Higher  Level  Management 


GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Ouantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Ouantitative  Objectives  for  the  Process 
GP  4.2  Stabilize  Subprocess  Performance 


GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 
GP  5.2  Correct  Root  Causes  of  Problems 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Product  Integration 


Preparation  for  product  integration  is  conducted.  [pau7.igioii 

Preparing  for  integration  of  product  components  involves  establishing 
and  maintaining  an  integration  sequence,  the  environment  for 
performing  the  integration,  and  integration  procedures.  The  specific 
practices  of  the  Prepare  for  Product  Integration  specific  goal  build  on 
each  other  in  the  following  way.  The  first  specific  practice  determines 
the  sequence  for  product  and  product-component  integration.  The 
second  determines  the  environment  that  will  be  used  to  carry  out  the 
product  and  product-component  integration.  The  third  develops 
procedures  and  criteria  for  product  and  product-component  integration. 
Preparation  for  integration  starts  early  in  the  project  and  the  integration 
sequence  is  developed  concurrently  with  the  practices  in  the  Technical 
Solution  process  area,  [pai47.igioi.nioi] 


SP  1.1-1  Determine  Integration  Sequence 

Determine  the  product-component  integration  sequence. 

[PA147.IG101  .SP101] 
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The  product  components  that  are  integrated  may  include  those  that  are 
a  part  of  the  product  to  be  delivered  along  with  test  equipment,  test 
software,  or  other  integration  items  such  as  fixtures.  Once  you  have 
analyzed  alternative  test  and  assembly  integration  sequences,  select 
the  best  integration  sequence,  [pai47.igioi.spioi.nioi] 

The  product  integration  sequence  can  provide  for  incremental  assembly 
and  evaluation  of  product  components  that  provide  a  problem-free 
foundation  for  incorporation  of  other  product  components  as  they 
become  available,  or  for  prototypes  of  high-risk  product  components. 

[PA147.IG101.SP101.N103] 


The  integration  sequence  should  be  harmonized  with  the  selection  of 
solutions  and  the  design  of  product  and  product  components  in  the 
Technical  Solution  process  area,  [pai47.igioi.spioi.nio4] 

Refer  to  the  Decision  Analysis  and  Resolution  process  area  for  more 
information  about  using  a  formal  evaluation  process  to  selecting  the 
appropriate  product  integration  sequence,  [pau7.igwi.spwi.nio4.rioi] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  handling  risks  associated  with  the  integration  sequence. 

[PA147.IG101.SP101.N104.R102] 

Refer  to  the  Supplier  Agreement  Management  process  area  for  more 
information  about  transitioning  acquired  product  components  and  the 
need  for  handling  those  product  components  in  the  product  integration 
sequence,  [pai47.igwi.spwi.nw4.rw3] 

Typical  Work  Products 

1.  Product  integration  sequence  [pai47.igioi.spioi.wioi] 

2.  Rationale  for  selecting  or  rejecting  integration  sequences 

[PA147.IG101.SP101.W102] 

Subpractices 

1 .  Identify  the  product  components  to  be  integrated. 

[PA147.IG101.SP101.SubP101] 

2.  Identify  the  product  integration  verifications  to  be  performed  using 
the  definition  of  the  interfaces  between  the  product  components. 

[PA147.IG101.SP101.SubP102] 

3.  Identify  alternative  product-component  integration  sequences. 

[PA147.IG101.SP101.SubP103] 

This  can  include  defining  the  specific  tools  and  test  equipment  to  support  the 
product  integration.  [PAi47.iGi01.sp101.subPi03.Ni0i] 

4.  Select  the  best  integration  sequence.  [PAi47.iGioi.spioi.subPios] 
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5.  Periodically  review  the  product  integration  sequence  and  revise  as 
needed.  [PAi47.iGioi.spioi.subPio6] 

Assess  the  product  integration  sequence  to  ensure  that  variations  in  production 
and  delivery  schedules  have  not  had  an  adverse  impact  on  the  sequence  or 
compromised  the  factors  upon  which  earlier  decisions  were  made. 

[PA147.IG101.SP101.SubP106.N101] 

6.  Record  the  rationale  for  decisions  made  and  deferred. 

[PA147.IG101.SP101.SubP107] 


SP  1.2-2  Establish  the  Product  Integration  Environment 

Establish  and  maintain  the  environment  needed  to  support  the 
integration  of  the  product  components,  [pau7.igwi.spw2] 


Refer  to  the  Technical  Solution  process  area  for  more  information  about 
make-or-buy  decisions,  [pau7.igwi.spw2.rwii 

The  environment  for  product  integration  can  either  be  acquired  or 
developed.  To  establish  an  environment,  requirements  for  the  purchase 
or  development  of  equipment,  software,  or  other  resources  will  need  to 
be  developed.  These  requirements  are  gathered  when  implementing 
the  processes  associated  with  the  Requirements  Development  process 
area.  The  product  integration  environment  may  include  the  reuse  of 
existing  organizational  resources.  The  decision  to  acquire  or  develop 
the  product  integration  environment  is  addressed  in  the  processes 
associated  with  the  Technical  Solution  process  area,  [pai47.igioi.spio2.nioi] 

The  environment  required  at  each  step  of  the  product  integration 
process  may  include  test  equipment,  simulators  (taking  the  place  of 
nonavailable  product  components),  pieces  of  real  equipment,  and 
recording  devices,  [pai47.igioi.spio2.nio2] 

Typical  Work  Products 

1 .  Verified  environment  for  product  integration  [pai47.igioi.spio2.wioi] 

2.  Support  documentation  for  the  product  integration  environment 

[PA147.IG101.SP102.W102] 

Subpractices 

1 .  Identify  the  requirements  for  the  product  integration  environment. 

[PA147.IG101.SP102.SubP101] 

2.  Identify  verification  criteria  and  procedures  for  the  product 
integration  environment,  [paw.igioi  spio2.subPio2] 

3.  Decide  whether  to  make  or  buy  the  needed  product  integration 
environment.  [PAi47.iGioi.spio2.subPio3] 
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Refer  to  the  Supplier  Agreement  Management  process  area  for 
more  information  about  acquiring  parts  of  the  integration 
environment.  [PAu7.iGio1.spw2.subPio3.Rioi] 


4.  Develop  an  integration  environment  if  a  suitable  environment 
cannot  be  acquired.  [PAi47.iGioi.spio2.subPio4] 

For  unprecedented,  complex  projects,  the  product  integration  environment  can  be 
a  major  development.  As  such,  it  would  involve  project  planning,  requirements 
development,  technical  solutions,  verification,  validation,  and  risk  management. 

[PA147.IG101.SP102.SubP104.N101] 

5.  Maintain  the  product  integration  environment  throughout  the 

project.  [PA147.IG101  ,SP102.SubP105] 

6.  Dispose  of  those  portions  of  the  environment  that  are  no  longer 

USeful.  [PA147.IG101.SP102.SubP106] 


SP  1.3-3  Establish  Product  Integration  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  integration  of 
the  product  components,  [pau7.igioi.spw3] 

Procedures  for  the  integration  of  the  product  components  can  include 
such  things  as  the  number  of  incremental  iterations  to  be  performed 
and  details  of  the  expected  tests  and  other  evaluations  to  be  carried  out 
at  each  stage,  [pah7.igioi.spio3.nio2] 

Criteria  can  indicate  the  readiness  of  a  product  component  for 
integration  or  its  acceptability,  [pah7.igioi.spio3.nio3] 

Procedures  and  criteria  for  product  integration  address  the  following: 

[PAH7.IG101.SP103.N105] 

•  Level  of  testing  for  build  components 

•  Verification  of  interfaces 

•  Thresholds  of  performance  deviation 

•  Derived  requirements  for  the  assembly  and  its  external  interfaces 

•  Allowable  substitutions  of  components 

•  Testing  environment  parameters 

•  Limits  on  cost  of  testing 

•  Quality/cost  tradeoffs  for  integration  operations 

•  Probability  of  proper  functioning 

•  Delivery  rate  and  its  variation 

•  Lead  time  from  order  to  delivery 
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•  Personnel  availability 

•  Availability  of  the  integration  facility/line/environment 

Criteria  can  be  defined  for  how  the  product  components  are  to  be 
verified  and  the  functions  they  are  expected  to  have.  Criteria  can  be 
defined  for  how  the  assembled  product  components  and  final  integrated 
product  are  to  be  validated  and  delivered,  [pai47.igioi.spio3.nio6] 

Criteria  may  also  constrain  the  degree  of  simulation  permitted  for  a 
product  component  to  pass  a  test,  or  may  constrain  the  environment  to 
be  used  for  the  integration  test,  [pai47.igioi.spio3.nio4] 

Typical  Work  Products 

1.  Product  integration  procedures  [pai47.igioi.spio3.wioi] 

2.  Product  integration  criteria  [pai47.igioi.spio3.wio2] 

Subpractices 

1 .  Establish  and  maintain  product  integration  procedures  for  the 
product  components.  [PAi47.iGioi.spio3.subPioi] 

2.  Establish  and  maintain  criteria  for  product-component  integration 
and  evaluation.  [PAi47.iGioi.spio3.subPio2] 

3.  Establish  and  maintain  criteria  for  validation  and  delivery  of  the 
integrated  product.  [PAi47.iGioi.spio3.subPio3] 


SG  2  Ensure  Interface  Compatibility 


The  product-component  interfaces,  both  internal  and  external,  are  compatible. 

[PA147.IG102] 

Many  product  integration  problems  arise  from  unknown  or  uncontrolled 
aspects  of  both  internal  and  external  interfaces.  Effective  management 
of  product-component  interface  requirements,  specifications,  and 
designs  helps  ensure  that  implemented  interfaces  will  be  complete  and 
compatible,  [pai47.igio2.nioi] 


SP  2.1-1  Review  Interface  Descriptions  for  Completeness 

Review  interface  descriptions  for  coverage  and  completeness. 

[PA147.IG102.SP101] 

The  interfaces  should  include,  in  addition  to  product-component 
interfaces,  all  the  interfaces  with  the  product  integration  environment. 

[PA147.IG102.SP101.N101] 

Typical  Work  Products 

1 .  Categories  of  interfaces  [pai47.igio2.spioi.wioi] 
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2.  List  of  interfaces  per  category  [pah7.igio2.spioi.wio2] 

3.  Mapping  of  the  interfaces  to  the  product  components  and  product 
integration  environment  [pah7.igio2.spioi.wio3] 

Subpractices 

1 .  Review  interface  data  for  completeness  and  ensure  complete 
coverage  of  all  interfaces.  [PAH7.iGio2.spioi.subPioi] 

Consider  all  the  product  components  and  prepare  a  relationship  table.  Interfaces 
are  usually  classified  in  three  main  classes:  environmental,  physical,  and 
functional.  Typical  categories  for  these  classes  include  the  following:  mechanical, 
fluid,  sound,  electrical,  climatic,  electromagnetic,  thermal,  message,  and  the 
human-machine  or  human  interface.  [PAi47.iGio2.sp101.subPio1.Nioi] 

For  Software  Engineering 

In  the  message  category  for  software,  interfaces  include  the 

following:  [PAU7.1G102.SP101  .SubPIOI .N101  .AMP101] 

•  Origination 

•  Destination 

•  Stimulus 

•  Protocols  and  data  characteristics 

2.  Ensure  that  product  components  and  interfaces  are  marked  to 
ensure  easy  and  correct  connection  to  the  joining  product 

component.  [PA147.IG102.SP101.SubP102] 

3.  Periodically  review  the  adequacy  of  interface  descriptions. 

[PA147.IG102.SP101.SubP103] 


Once  established,  the  interface  descriptions  must  be  periodically  reviewed  to 
ensure  there  is  no  deviation  between  the  existing  descriptions  and  the  products 
being  developed,  processed,  produced,  or  bought.  [PAi47.iGio2.sp101.subPio3.Nioi] 


SP  2.2-1  Manage  Interfaces 

Manage  internal  and  external  interface  definitions,  designs,  and 
changes  for  products  and  product  components.  [PA147.1G102.SP1021 


Interface  requirements  drive  the  development  of  the  interfaces 
necessary  to  integrate  product  components.  Managing  product  and 
product-component  interfaces  starts  very  early  in  the  development  of 
the  product.  The  definitions  and  designs  for  interfaces  affect  not  only 
the  product  components  and  external  systems,  but  can  also  affect  the 
verification  and  validation  environments,  [pah7.igio2.spio2.nio4] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  for  interfaces.  [pau7.igw2.spio2.nio4.rwi] 
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Refer  to  the  Technical  Solution  process  area  for  more  information  about 
design  of  interfaces  between  product  components,  [pau7.igw2.spw2.nio4.rio2] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  the  changes  to  the  interface  requirements. 

[PA147.IG102.SP102.N104.R103] 

Refer  to  the  Configuration  Management  process  area  for  more 
information  about  distributing  changes  to  the  interface  descriptions 
(specifications),  so  that  everyone  can  know  the  current  state  of  the 

interfaces.  [PA147.IGW2.SPW2.NW4.R104] 

Management  of  the  interfaces  includes  maintenance  of  the  consistency 
of  the  interfaces  throughout  the  life  of  the  product,  and  resolution  of 
conflict,  noncompliance,  and  change  issues,  [pah7.igio2.spio2.nioi] 

The  interfaces  should  include,  in  addition  to  product-component 
interfaces,  all  the  interfaces  with  the  environment  as  well  as  other 
environments  for  verification,  validation,  operations,  and  support. 

[PA147.IG102.SP102.N102] 

The  interface  changes  are  documented,  maintained,  and  readily 

accessible.  [PAH7.IG102.SP102.N103] 

Typical  Work  Products 

1 .  Table  of  relationships  among  the  product  components  and  the 
external  environment  (e.g.,  main  power  supply,  fastening  product, 
computer  bus  system)  [pah7.igio2.spio2.wioi] 

2.  Table  of  relationships  between  the  different  product  components 

[PAH7.IG102.SP102.W102] 

3.  List  of  agreed-to  interfaces  defined  for  each  pair  of  product 
components,  when  applicable  [pah7.igio2.spio2.wio3] 

4.  Reports  from  the  interface  control  working  group  meetings 

[PAH7.IG102.SP102.W104] 

5.  Action  items  for  updating  interfaces  [pah7.igio2.spio2.wio5] 

6.  Application  program  interface  (API)  [pah7.igio2.spio2.wio6] 

7.  Updated  interface  description  or  agreement  [pah7.igio2.spio2.wio7] 

Subpractices 

1 .  Ensure  the  compatibility  of  the  interfaces  throughout  the  life  of  the 

product.  [PAH7.IG102.SP1 02. SubPI 01] 

2.  Resolve  conflict,  noncompliance,  and  change  issues. 

[PA147.IG102.SP102.SubP102] 
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3.  Maintain  a  repository  for  interface  data  accessible  to  project 

participants.  [PA147.IG102.SP102.SubP103] 

A  common  accessible  repository  for  interface  data  provides  a  mechanism  to 
ensure  that  everyone  knows  where  the  current  interface  data  resides  and  can 
access  it  for  use.  [PAi47.iGi02.sp102.subPi03.Ni0i] 


SG  3  Assemble  Product  Components  and  Deliver  the  Product 


Verified  product  components  are  assembled  and  the  integrated,  verified,  and 
validated  product  is  delivered.  [pau7.igio3] 

Integration  of  product  components  proceeds  according  to  the  product 
integration  sequence  and  available  procedures.  Before  integration, 
each  product  component  should  be  confirmed  to  be  compliant  with  its 
interface  requirements.  Product  components  are  assembled  into  larger, 
more  complex  product  components.  These  assembled  product 
components  are  checked  for  correct  interoperation.  This  process 
continues  until  product  integration  is  complete.  If,  during  this  process, 
problems  are  identified,  the  problem  should  be  documented  and  a 
corrective  action  process  initiated,  [pai47.igio3.nioi] 

Ensure  that  the  assembly  of  the  product  components  into  larger  and 
more  complex  product  components  is  conducted  according  to  the 
product  integration  sequence  and  available  procedures.  The  timely 
receipt  of  needed  product  components  and  the  involvement  of  the  right 
people  contribute  to  the  successful  integration  of  the  product 
components  that  compose  the  product,  [pam7.igio3.nio2] 


SP  3.1-1  Confirm  Readiness  of  Product  Components  for  Integration 

Confirm,  prior  to  assembly,  that  each  product  component  required 
to  assemble  the  product  has  been  properly  identified,  functions 
according  to  its  description,  and  that  the  product-component 
interfaces  comply  with  the  interface  descriptions.  [pau7.igio3.spioi] 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  product  components,  [pau7.igio3.spioi.rioi] 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
unit  test  of  product  components,  [pau7.igio3.spioi.rio2] 

The  purpose  of  this  specific  practice  is  to  ensure  that  the  properly 
identified  product  component  that  meets  its  description  can  actually  be 
assembled  according  to  the  product  integration  sequence  and  available 
procedures.  The  product  components  are  checked  for  quantity,  obvious 
damage,  and  consistency  between  the  product  component  and 
interface  descriptions,  [pam7.igio3.spioi.nioi] 
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Those  conducting  product  integration  are  ultimately  responsible  for 
checking  to  make  sure  everything  is  proper  with  the  product 
components  before  assembly,  [pai47.igio3.spioi.nio2] 

Typical  Work  Products 

1 .  Acceptance  documents  for  the  received  product  components 

[PA147.IG103.SP101.W101] 

2.  Delivery  receipts  [PAi47.iGi03.sp101.w102] 

3.  Checked  packing  lists  [pai47.igio3.spioi.wio3] 

4.  Exception  reports  [pai47.igio3.spioi.wio4] 

5.  Waivers  [PA147.IG103.SP101.W105] 

Subpractices 

1 .  T rack  the  status  of  all  product  components  as  soon  as  they 
become  available  for  integration.  [PAi47.iGio3.spioi.subPioi] 

2.  Ensure  that  product  components  are  delivered  to  the  product 
integration  environment  in  accordance  with  the  product  integration 
sequence  and  available  procedures.  [PAi47.iGio3.spioi.subPio2] 

3.  Confirm  the  receipt  of  each  properly  identified  product  component. 

[PA147.IG103.SP101.SubP103] 

4.  Ensure  that  each  received  product  component  meets  its 
description.  [PAi47.iGio3.spioi.subPio4] 

5.  Check  the  configuration  status  against  the  expected  configuration. 

[PA147.IG103.SP101.SubP105] 

6.  Perform  pre-check  (for  example,  by  a  visual  inspection  and  using 
basic  measures)  of  all  the  physical  interfaces  before  connecting 
product  components  together.  [PAi47.iGio3.spioi.subPio6] 


SP  3.2-1  Assemble  Product  Components 

Assemble  product  components  according  to  the  product 
integration  sequence  and  available  procedures.  [pau7.igio3.spio2i 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  assembled  product  components,  [pau7.igio3.spw2.rioi] 

Refer  to  the  Validation  process  area  for  more  information  about 
validating  assembled  product  components,  [pau7.igio3.spio2.rio2] 
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(For  users  of  the  continuous  representation,  this  is  a  capability  level  1 
specific  practice.  Product  integration  processes  at  capability  level  1  or  2 
may  not  include  procedures  and  criteria,  which  are  created  in  the 
Establish  Product  Integration  Procedures  and  Criteria  specific  practice 
at  capability  level  3.  When  there  are  no  procedures  or  criteria 
established,  use  the  sequence  established  by  the  Determine  Integration 
Sequence  specific  practice  to  accomplish  capability  level  1 
performance.)  [PAi47.iGi03.sp102.Ni02] 

The  assembly  activities  of  this  specific  practice  and  the  evaluation 
activities  of  the  next  specific  practice  are  conducted  iteratively,  from  the 
initial  product  components,  through  the  interim  assemblies  of  product 
components,  to  the  product  as  a  whole,  [pai47.igio3.spio2.nioi] 

Typical  Work  Products 

1 .  Assembled  product  or  product  components  [PAi47.iGi03.sp102.w10i] 

Subpractices 

1 .  Ensure  the  readiness  of  the  product  integration  environment. 

[PA147.IG103.SP102.SubP101] 

2.  Ensure  that  the  assembly  sequence  is  properly  performed. 

[PA147.IG103.SP102.SubP102] 

Record  all  appropriate  information  (e.g.,  configuration  status,  serial  numbers  of 
the  product  components,  types,  and  calibration  date  of  the  meters). 

[PA147.IG103.SP102.SubP102.N101] 

3.  Revise  the  product  integration  sequence  and  available  procedures 
as  appropriate.  [PAi47.iGio3.spio2.subPio4] 


SP  3.3-1  Evaluate  Assembled  Product  Components 

Evaluate  assembled  product  components  for  interface 
compatibility.  [pau7.igio3.spio3] 
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This  evaluation  involves  examining  and  testing  assembled  product 
components  for  performance,  suitability,  or  readiness  using  the 
available  procedures  and  environment.  It  is  performed  as  appropriate 
for  different  stages  of  assembly  of  product  components  as  identified  in 
the  product  integration  sequence  and  available  procedures.  The 
product  integration  sequence  and  available  procedures  may  define  a 
more  refined  integration  and  evaluation  sequence  than  might  be 
envisioned  just  by  examining  the  product  architecture.  For  example,  if 
an  assembly  of  product  components  is  composed  of  four  less  complex 
product  components,  the  integration  sequence  will  not  necessarily  call 
for  the  simultaneous  integration  and  evaluation  of  the  four  units  as  one. 
Rather,  the  four  less  complex  units  may  be  integrated  progressively, 
one  at  a  time,  with  an  evaluation  after  each  assembly  operation  prior  to 
realizing  the  more  complex  product  component  that  matched  the 
specification  in  the  product  architecture.  Alternatively,  the  integration 
sequence  and  available  procedures  could  have  determined  that  only  a 
final  evaluation  was  the  best  one  to  perform,  [pai47.igio3.spio3.nioi] 

Typical  Work  Products 

1 .  Exception  reports  [PAi47.iGi03.sp103.w102] 

2.  Interface  evaluation  reports  [pai47.igio3.spio3.wio3] 

3.  Product  integration  summary  reports  [pai47.igio3.spio3.wio4] 

Subpractices 

1 .  Conduct  the  evaluation  of  assembled  product  components 
following  the  product  integration  sequence  and  available 
procedures.  [PAi47.iGio3.spio3.subPioi] 

2.  Record  the  evaluation  results.  [PAi47.iGio3.spio3.subPio2] 


Example  results  include  the  following:  [PAi47.iGi03.sp103.subPi02.Ni0i] 

•  Any  adaptation  required  to  the  integration  procedure 

•  Any  change  to  the  product  configuration  (spare  parts,  new  release) 

•  Evaluation  procedure  deviations 


SP  3.4-1  Package  and  Deliver  the  Product  or  Product  Component 

Package  the  assembled  product  or  product  component  and  deliver 
it  to  the  appropriate  customer.  [pau7.igio3.spw4] 


Refer  to  the  Verification  process  area  for  more  information  about 
verifying  the  product  or  an  assembly  of  product  components  before 
packaging,  [pau7.igw3.spio4.rioi] 
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Refer  to  the  Validation  process  area  for  more  information  about 
validating  the  product  or  an  assembly  of  product  components  before 
packaging,  [pau7.igw3.spio4.rio2] 

The  packaging  requirements  for  some  products  may  be  addressed  in 
their  specifications  and  verification  criteria.  This  is  especially  important 
when  items  are  stored  and  transported  by  the  customer.  In  such  cases, 
there  may  be  a  spectrum  of  environmental  and  stress  conditions 
specified  for  the  package.  In  other  circumstances,  factors  such  as  the 
following  may  become  important:  [pai47.igio3.spio4.nioi] 

•  Economy  and  ease  of  transportation  (e.g.,  containerization) 

•  Accountability  (e.g.,  shrinkwrapping) 

•  Ease  and  safety  of  unpacking  (e.g.,  sharp  edges,  strength  of 
binding  methods,  childproofing,  environmental  friendliness  of 
packing  material,  weight) 

The  adjustment  required  to  fit  product  components  together  in  the 
factory  could  be  different  from  the  one  required  to  fit  product 
components  when  installed  on  the  operational  site.  In  that  case,  the 
product's  logbook  for  the  customer  should  be  used  to  record  such 
specific  parameters.  [PAi47.iGi03.sp104.Ni02] 

Typical  Work  Products 

1 .  Packaged  product  or  product  components  [pai47.igio3.spio4.wioi] 

2.  Delivery  documentation  [pai47.igio3.spio4.wio2] 

Subpractices 

1.  Review  the  requirements,  design,  product,  verification  results,  and 
documentation  to  ensure  that  issues  affecting  the  packaging  and 
delivery  of  the  product  are  identified  and  resolved. 

[PA147.IG103.SP104.SubP101] 

2.  Use  effective  methods  to  package  and  deliver  the  assembled 

prOdUCt.  [PA147.IG103.SP104.SubP102] 

For  Software  Engineering 

Examples  of  software  packaging  and  delivery  methods  include  the  following: 

[PA147.IG103.SP104.SubP102.AMP101] 

•  Magnetic  tape 

•  Diskettes 

•  Hardcopy  documents 

•  Compact  disks 

•  Other  electronic  distribution  such  as  the  Internet 
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3.  Satisfy  the  applicable  requirements  and  standards  for  packaging 
and  delivering  the  product.  [PAi47.iGio3.spio4.subPio3] 

For  Software  Engineering 

Examples  of  requirements  and  standards  for  packaging  and  delivering  the 
software  include  the  following:  pAw.iGi03.sp104.subPi03.AMPm 

•  Type  of  storage  and  delivery  media 

•  Custodians  of  the  master  and  backup  copies  of  the  software 

•  Required  documentation 

•  Copyrights 

•  License  provisions 

•  Security  of  the  software 

4.  Prepare  the  operational  site  for  installation  of  the  product. 

[PA147.IG103.SP104.SubP104] 

Preparing  the  operational  site  may  be  the  responsibility  of  the  customer  or  end 

USerS.  [PA147.IG103.SP104.SubP104.N101] 

5.  Deliver  the  product  and  related  documentation  and  confirm  receipt. 

[PA147.IG103.SP104.SubP105] 

6.  Install  the  product  at  the  operational  site  and  confirm  correct 

operation.  [PA147.IG103.SP104.SubP106] 

Installing  the  product  may  be  the  responsibility  of  the  customer  or  end  users.  In 
some  circumstances,  very  little  may  need  to  be  done  to  confirm  correct  operation. 
In  other  circumstances,  final  verification  of  the  integrated  product  occurs  at  the 
operational  site.  [PAi47.iGio3.sp104.subPio6.Nioi] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  product  integration  process  to 
develop  work  products  and  provide  services  to  achieve  the 
specific  goals  of  the  process  area.  [GP102] 
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GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  product  integration  process,  [gpio3j 


Elaboration: 

This  policy  establishes  organizational  expectations  for  developing 
product  integration  sequences,  procedures,  and  an  environment, 
ensuring  interface  compatibility  among  product  components, 
assembling  the  product  components,  and  delivering  the  product  and 
product  components,  [paw.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  product 
integration  process,  [gpiov 


Elaboration: 

This  plan  for  performing  the  product  integration  process  addresses  the 
comprehensive  planning  for  all  of  the  specific  practices  in  this  process 
area,  from  the  preparation  for  product  integration  all  the  way  through  to 
the  delivery  of  the  final  product.  [paw.elkk] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  product  integration 
process,  developing  the  work  products,  and  providing  the  services 
of  the  process,  [gpiosi 


Elaboration: 

Product-component  interface  coordination  may  be  accomplished  with 
an  Interface  Control  Working  Group  consisting  of  people  who  represent 
external  and  internal  interfaces.  Such  groups  can  be  used  to  elicit 
needs  for  interface  requirements  development,  [paw.elhs] 

Special  facilities  may  be  required  for  assembling  and  delivering  the 
product.  When  necessary,  the  facilities  required  for  the  activities  in  the 
Product  Integration  process  area  are  developed  or  purchased.  [pam7elh6] 
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Examples  of  other  resources  provided  include  the  following  tools:  [pai47.elh7] 

•  Prototyping  tools 

•  Analysis  tools 

•  Simulation  tools 

•  Interface  management  tools 

•  Assembly  tools  (e.g.,  compilers,  make  files,  joining  tools,  jigs  and  fixtures) 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
product  integration  process,  [gpiobj 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  product  integration 
process  as  needed.  [gpio7i 

Elaboration: 

Examples  of  training  topics  include  the  following:  [paw.eliosi 

•  Application  domain 

•  Product  integration  procedures  and  criteria 

•  Organization's  facilities  for  integration  and  assembly 

•  Assembly  methods 

•  Packaging  standards 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  product  integration 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 
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Elaboration: 


Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai47.elio6] 

•  Acceptance  documents  for  the  received  product  components 

•  Evaluated  assembled  product  and  product  components 

•  Product  integration  sequence 

•  Product  integration  procedures  and  criteria 

•  Updated  interface  description  or  agreement 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  product 
integration  process  as  planned.  [gpi24] 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process.  [pai47.eh20] 


Examples  of  activities  for  stakeholder  involvement  include  the  following:  [PA147.EL121] 

•  Reviewing  interface  descriptions  for  completeness 

•  Establishing  the  product  integration  sequence 

•  Establishing  the  product  integration  procedures  and  criteria 

•  Assembling  and  delivering  the  product  and  product  components 

•  Communicating  the  results  after  evaluation 

•  Communicating  new,  effective  product  integration  processes  to  give  affected 
people  the  opportunity  to  improve  their  performance 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  product  integration  process  against  the 
plan  for  performing  the  process  and  take  appropriate  corrective 
action,  [gpuoj 
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Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA147.EL112] 

•  Product-component  integration  profile  (e.g.,  product-component  assemblies 
planned  and  performed,  and  number  of  exceptions  found) 

•  Integration  evaluation  problem  report  trends  (e.g.,  number  written  and  number 
closed) 

•  Integration  evaluation  problem  report  aging  (i.e.,  how  long  each  problem  report 
has  been  open) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  product  integration  process 
against  its  process  description,  standards,  and  procedures,  and 
address  noncompliance,  [gpiuj 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai47.elh4] 

•  Establishing  and  maintaining  a  product  integration  sequence 

•  Ensuring  interface  compatibility 

•  Assembling  product  components  and  delivering  the  product 

Examples  of  work  products  reviewed  include  the  following:  [paw.eliis] 

•  Product  integration  sequence 

•  Product  integration  procedures  and  criteria 

•  Acceptance  documents  for  the  received  product  components 

•  Assembled  product  and  product  components 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  product  integration 
process  with  higher  level  management  and  resolve  issues.  igph2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 
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GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  product 
integration  process,  [g  piuj 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  product  integration  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[GP117] 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  product 
integration  process  that  address  quality  and  process  performance 
based  on  customer  needs  and  business  objectives,  [gpusj 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  product  integration  process  to  achieve 
the  established  quantitative  quality  and  process-performance 
objectives,  [gph9] 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  product  integration 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP1251 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  product  integration  process.  [GP121] 
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VERIFICATION 

Engineering 


Purpose 


The  purpose  of  Verification  is  to  ensure  that  selected  work  products 
meet  their  specified  requirements,  [paiso] 


Introductory  Notes 


The  Verification  process  area  involves  the  following:  verification 
preparation,  verification  performance,  and  identification  of  corrective 
action,  [paiso.nioi] 

Verification  includes  verification  of  the  product  and  intermediate  work 
products  against  all  selected  requirements,  including  customer,  product, 
and  product-component  requirements.  [paiso.nio2] 

Verification  is  inherently  an  incremental  process  because  it  occurs 
throughout  the  development  of  the  product  and  work  products, 
beginning  with  verification  of  the  requirements,  progressing  through  the 
verification  of  the  evolving  work  products,  and  culminating  in  the 
verification  of  the  completed  product.  [paiso.nio3] 

The  specific  practices  of  this  process  area  build  upon  each  other  in  the 
following  way:  the  Select  Work  Products  for  Verification  specific  practice 
enables  the  identification  of  the  work  products  to  be  verified,  the 
methods  to  be  used  to  perform  the  verification,  and  the  requirements  to 
be  satisfied  by  each  selected  work  product.  The  Establish  the 
Verification  Environment  specific  practice  enables  the  determination  of 
the  environment  that  will  be  used  to  carry  out  the  verification.  The 
Establish  Verification  Procedures  and  Criteria  specific  practice  then 
enables  the  development  of  verification  procedures  and  criteria  that  are 
aligned  with  the  selected  work  products,  requirements,  methods,  and 
characteristics  of  the  verification  environment.  The  Perform  Verification 
specific  practice  conducts  the  verification  according  to  the  available 
methods,  procedures,  and  criteria,  [paisonuo] 

Verification  of  work  products  substantially  increases  the  likelihood  that 
the  product  will  meet  the  customer,  product,  and  product-component 
requirements,  [paiso.nkm] 
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The  Verification  and  Validation  process  areas  are  similar,  but  they 
address  different  issues.  Validation  demonstrates  that  the  product,  as 
provided  (or  as  it  will  be  provided),  will  fulfill  its  intended  use,  whereas 
verification  addresses  whether  the  work  product  properly  reflects  the 
specified  requirements.  In  other  words,  verification  ensures  that  “you 
built  it  right;”  whereas,  validation  ensures  that  “you  built  the  right  thing.” 

[PA150.N105] 


Peer  reviews  are  an  important  part  of  verification  and  are  a  proven 
mechanism  for  effective  defect  removal.  An  important  corollary  is  to 
develop  a  better  understanding  of  the  work  products  and  the  processes 
that  produced  them  so  defects  can  be  prevented  and  process- 
improvement  opportunities  can  be  identified.  [PA150.N106] 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers'  peers  to  identify  defects  and  other  changes  that  are  needed. 

[PA150.N107] 


Examples  of  peer  review  methods  include  the  following:  [paiso.nios] 

•  Inspections 

•  Structured  walkthroughs 


Related  Process  Areas 


Refer  to  the  Validation  process  area  for  more  information  about 
confirming  that  a  product  or  product  component  fulfills  its  intended  use 
when  placed  in  its  intended  environment.  [PM50.R1021 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  the  generation  and  development  of  customer, 
product,  and  product-component  requirements.  [paiso.rio3] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  managing  requirements.  [pmso.rio4] 


Specific  Goals 


SG  1  Prepare  for  Verification  [paiso.igioij 


Preparation  for  verification  is  conducted. 


SG  2  Perform  Peer  Reviews  [paiso  10102] 


Peer  reviews  are  performed  on  selected  work  products. 
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Selected  work  products  are  verified  against  their  specified  requirements. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Prepare  for  Verification  [paiso.igioii 

SP  1.1-1  Select  Work  Products  for  Verification 
SP  1.2-2  Establish  the  Verification  Environment 
SP  1.3-3  Establish  Verification  Procedures  and  Criteria 

SG  2  Perform  Peer  Reviews  [paiso.igkk] 

SP  2.1-1  Prepare  for  Peer  Reviews 
SP  2.2-1  Conduct  Peer  Reviews 

SP  2.3-2  Analyze  Peer  Review  Data 

SG  3  Verify  Selected  Work  Products  [PA150.IG103] 

SP  3.1-1  Perform  Verification 

SP  3.2-2  Analyze  Verification  Results  and  Identify  Corrective  Action 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 
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GG  2  Institutionalize  a 
GP  2.1 
GP  2.2 
GP  2.3 
GP  2.4 
GP  2.5 
GP  2.6 
GP  2.7 
GP  2.8 
GP  2.9 
GP  2.10 


Managed  Process  [clio3.ghoi] 

Establish  an  Organizational  Policy 

Plan  the  Process 

Provide  Resources 

Assign  Responsibility 

Train  People 

Manage  Configurations 

Identify  and  Involve  Relevant  Stakeholders 

Monitor  and  Control  the  Process 

Objectively  Evaluate  Adherence 

Review  Status  with  Higher  Level  Management 


GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 


GG  4  Institutionalize  a  Ouantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Ouantitative  Objectives  for  the  Process 
GP  4.2  Stabilize  Subprocess  Performance 


GG  5  Institutionalize  an  Optimizing  Process  [clioo.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 
GP  5.2  Correct  Root  Causes  of  Problems 


Specific  Practices  by  Goal 


SG  1  Prepare  for  Verification 


Preparation  for  verification  is  conducted,  [paiso.igiov 

Up-front  preparation  is  necessary  to  ensure  that  verification  provisions 
are  embedded  in  product  and  product-component  requirements, 
designs,  developmental  plans,  and  schedules.  Verification  includes 
selection,  inspection,  testing,  analyses,  and  demonstration  of  work 

products.  [PA150.IG101.N101] 

Methods  of  verification  include,  but  are  not  limited  to,  inspections,  peer 
reviews,  audits,  walkthroughs,  analyses,  simulations,  testing,  and 
demonstrations,  [pai5o.igioi.nio2] 

Preparation  also  entails  the  definition  of  support  tools,  test  equipment 
and  software,  simulations,  prototypes,  and  facilities,  [paiso.igioi.nio3] 


SP  1.1-1  Select  Work  Products  for  Verification 

Select  the  work  products  to  be  verified  and  the  verification 
methods  that  will  be  used  for  each.  / paiso.igioi.spioi i 
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Work  products  are  selected  based  on  their  contribution  to  meeting 
project  objectives  and  requirements,  and  to  addressing  project  risks. 

[PA150.IG101.SP101.N104] 


The  work  products  to  be  verified  may  include  those  associated  with 
maintenance,  training,  and  support  services.  The  work  product 
requirements  for  verification  are  included  with  the  verification  methods. 
The  verification  methods  address  the  technical  approach  to  work 
product  verification  and  the  specific  approaches  that  will  be  used  to 
verify  that  specific  work  products  meet  their  requirements. 

[PA150.IG101.SP101.N102] 

For  Software  Engineering 

Examples  of  verification  methods  include  the  following: 

[PA1 50.IG1 01  .SP101  ,N1 02.AMP101] 

•  Path  coverage  testing 

•  Load,  stress,  and  performance  testing 

•  Decision-table-based  testing 

•  Functional-decomposition-based  testing 

•  Test-case  reuse 

•  Acceptance  tests 


Selection  of  the  verification  methods  typically  begins  with  involvement  in 
the  definition  of  product  and  product-component  requirements  to  ensure 
that  these  requirements  are  verifiable.  Re-verification  should  be 
addressed  by  the  verification  methods  to  ensure  that  rework  performed 
on  work  products  did  not  cause  unintended  defects,  [pai5o.igioi.spioi.nio3] 

Typical  Work  Products 

1 .  Lists  of  work  products  selected  for  verification  [paiso.igioi.spioi.wioi] 

2.  Verification  methods  for  each  selected  work  product 

[PA150.IG101.SP101.W102] 

Subpractices 

1 .  Identify  work  products  for  verification.  [PAi5o.iGioi.spioi.subPio2] 

2.  Identify  the  requirements  to  be  satisfied  by  each  selected  work 

prOdUCt.  [PA150.IG101.SP101.SubP103] 

Refer  to  the  Maintain  Bidirectional  Traceability  of  Requirements 
specific  practice  in  the  Requirements  Management  process  area  to 
help  identify  the  requirements  for  each  work  product. 

[PA150.IG101.SP101.SubP103.R101] 

3.  Identify  the  verification  methods  that  are  available  for  use. 

[PA150.IG101.SP101.SubP104] 
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4.  Define  the  verification  methods  to  be  used  for  each  selected  work 

prOdUCt.  [PA150.IG101.SP101.SubP105] 

5.  Submit  for  integration  with  the  project  plan  the  identification  of  work 
products  to  be  verified,  the  requirements  to  be  satisfied,  and  the 
methods  to  be  used.  [PAi5o.iGioi.spioi.subPio6] 

Refer  to  the  Project  Planning  process  area  for  information  on 
coordinating  with  project  planning.  iPMso.iGioi.spioi.subPioe.Rioi] 


SP  1.2-2  Establish  the  Verification  Environment 

Establish  and  maintain  the  environment  needed  to  support 
verification,  [paiso.igioi.spw2] 


An  environment  must  be  established  to  enable  verification  to  take  place. 
The  verification  environment  may  be  acquired,  developed,  reused, 
modified,  ora  combination  of  these,  depending  on  the  needs  of  the 

project.  [PA150.IG101.SP102.N101] 

The  type  of  environment  required  will  depend  on  the  work  products 
selected  for  verification  and  the  verification  methods  used.  A  peer 
review  may  require  little  more  than  a  package  of  materials,  reviewers, 
and  a  room.  A  product  test  may  require  simulators,  emulators,  scenario 
generators,  data  reduction  tools,  environmental  controls,  and  interfaces 
with  other  systems,  [pai5o.igioi.spio2.nio2] 

Typical  Work  Products 

1.  Verification  environment  [pai5o.igioi.spio2.wio2] 

Subpractices 

1.  Identify  verification  environment  requirements.  [PAiso.iGioi.spio2.subPioi] 

2.  Identify  verification  resources  that  are  available  for  reuse  and 
modification.  [PAiso.iGioi.spio2.subPio2] 

3.  Identify  verification  equipment  and  tools.  [PAiso.iGioi.spio2.subPio3] 

4.  Acquire  verification  support  equipment  and  an  environment,  such 
as  test  equipment  and  software.  [PAi5o.iGioi.spio2.subPio4] 


SP  1.3-3  Establish  Verification  Procedures  and  Criteria 

Establish  and  maintain  verification  procedures  and  criteria  for  the 
selected  work  products,  [paiso.igioi.spw3] 


Verification  criteria  are  defined  to  ensure  that  the  work  products  meet 
their  requirements,  [pai5o.igioi.spio3.nioi] 
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Examples  of  sources  for  verification  criteria  include  the  following:  [pai5o.igioi.spio3.mo2] 

•  Product  and  product-component  requirements 

•  Standards 

•  Organizational  policies 

•  Test  type 

•  Test  parameters 

•  Parameters  for  tradeoff  between  quality  and  cost  of  testing 

•  Type  of  work  products 


Typical  Work  Products 

1.  Verification  procedures  [pai5o.igioi.spio3.wioi] 

2.  Verification  criteria  ipai5o.igioi.spio3.wio2] 

Subpractices 

1 .  Generate  the  set  of  comprehensive,  integrated  verification 
procedures  for  work  products  and  any  commercial  off-the-shelf 
products,  as  necessary.  [PAiso.iGioi.spio3.subPioi] 

2.  Develop  and  refine  the  verification  criteria  when  necessary. 

[PA150.IG101.SP103.SubP102] 

3.  Identify  the  expected  results,  any  tolerances  allowed  in 
observation,  and  other  criteria  for  satisfying  the  requirements. 

[PA1 50.IG1 01  .SP1 03.SubP1 04] 

4.  Identify  any  equipment  and  environmental  components  needed  to 
support  verification.  [PAiso.iGioi.spio3.subPio5] 


SG  2  Perform  Peer  Reviews 


Peer  reviews  are  performed  on  selected  work  products.  [paiso.igio2] 

Peer  reviews  involve  a  methodical  examination  of  work  products  by  the 
producers'  peers  to  identify  defects  for  removal  and  to  recommend 
other  changes  that  are  needed,  [pai5o.igio2.nioi] 

The  peer  review  is  an  important  and  effective  engineering  method 
implemented  via  inspections,  structured  walkthroughs,  ora  number  of 
other  collegial  review  methods.  [PAi50.iGi02.Ni02] 

Peer  reviews  are  primarily  applied  to  work  products  developed  by  the 
projects,  but  they  can  also  be  applied  to  other  work  products  such  as 
documentation  and  training  work  products  that  are  typically  developed 
by  support  groups.  [PAi50.iGi02.Ni03] 
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SP  2.1-1  Prepare  for  Peer  Reviews 

Prepare  for  peer  reviews  of  selected  work  products,  [paiso.igio2.spwi] 

Preparation  activities  for  peer  reviews  typically  include  identifying  the 
staff  who  will  be  invited  to  participate  in  the  peer  review  of  each  work 
product,  identifying  the  key  reviewers  who  must  participate  in  the  peer 
review,  preparing  and  updating  any  materials  that  will  be  used  during 
the  peer  reviews  (such  as  checklists  and  review  criteria),  and 
scheduling  peer  reviews,  [paiso.igio2.spioi.nioi] 

Typical  Work  Products 

1 .  Peer  review  schedule  [paiso.igio2.spioi.wioi] 

2.  Peer  review  checklist  [paiso.igio2.spioi.wio2] 

3.  Entry  and  exit  criteria  for  work  products  [paiso.igio2.spioi.wio3] 

4.  Criteria  for  requiring  another  peer  review  [paiso.igio2.spioi.wio4] 

5.  Peer  review  training  material  [paiso.igio2.spioi.wios] 

6.  Selected  work  products  to  be  reviewed  [paiso.igio2.spioi.wio6] 

Subpractices 

1 .  Determine  what  type  of  peer  review  will  be  conducted. 

[PA150.IG102.SP101.SubP101] 

Examples  of  types  of  peer  reviews  include  the  following:  [PAi50.iGi02.sp101.subPi01.Ni0i] 

•  Inspections 

•  Structured  walkthroughs 

•  Active  reviews 


2.  Define  requirements  for  collecting  data  during  the  peer  review. 

[PA150.IG102.SP101.SubP102] 

Refer  to  the  Measurement  and  Analysis  process  area  for 
information  on  identifying  and  collecting  data. 

[PA150.IG102.SP101.SubP102.R101] 

3.  Establish  and  maintain  entry  and  exit  criteria  for  the  peer  review. 

[PA150.IG102.SP1 01. SubPI  03] 

4.  Establish  and  maintain  criteria  for  requiring  another  peer  review. 

[PA1 50.IG1 02.SP1 01  .SubPI  04] 

5.  Establish  and  maintain  checklists  to  ensure  that  the  work  products 
are  reviewed  consistently.  [PAiso.iGio2.spioi.subPio5] 
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Examples  of  items  addressed  by  the  checklists  include  the  following: 

[PA150.IG102.SP101.SubP105.N102] 

•  Rules  of  construction 

•  Design  guidelines 

•  Completeness 

•  Correctness 

•  Maintainability 

•  Common  defect  types 


The  checklists  are  modified  as  necessary  to  address  the  specific  type  of  work 
product  and  peer  review.  The  peers  of  the  checklist  developers  and  potential 
users  review  the  checklists.  [PAi50.iGio2.sp1o1.subPio5.Nioi] 

6.  Develop  a  detailed  peer  review  schedule,  including  the  dates  for 
peer  review  training  and  for  when  materials  for  peer  reviews  will  be 
available.  [PAi5o.iGio2.spioi.subPio6] 

7.  Ensure  that  the  work  product  satisfies  the  peer  review  entry  criteria 
prior  to  distribution.  [PAi5o.iGio2.spioi.subPio7] 

8.  Distribute  the  work  product  to  be  reviewed  and  its  related 
information  to  the  participants  early  enough  to  enable  participants 
to  adequately  prepare  for  the  peer  review.  [PAi5o.iGio2.spioi.subPio8] 

9.  Assign  roles  for  the  peer  review  as  appropriate.  [PAi5o.iGio2.spioi.subPio9] 


Examples  of  roles  include  the  following:  [PAi50.iGi02.sp101.subPi09.Ni0i] 

•  Leader 

•  Reader 

•  Recorder 

•  Author 

1 0.  Prepare  for  the  peer  review  by  reviewing  the  work  product  prior  to 
conducting  the  peer  review.  [PAi5o.iGio2.spioi.subPiio] 


SP  2.2-1  Conduct  Peer  Reviews 

Conduct  peer  reviews  on  selected  work  products  and  identify 
issues  resulting  from  the  peer  review,  [paiso.igio2.spi 021 


One  of  the  purposes  of  conducting  a  peer  review  is  to  find  and  remove 
defects  early.  Peer  reviews  are  performed  incrementally,  as  work 
products  are  being  developed.  These  reviews  are  structured  and  are 
not  management  reviews.  [PAi50.iGi02.sp102.Ni0i] 
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Peer  reviews  may  be  performed  on  key  work  products  of  specification, 
design,  test,  and  implementation  activities  and  specific  planning  work 

prOdUCtS.  [PA150.IG102.SP102.N102] 

The  focus  of  the  peer  review  should  be  on  the  work  product  in  review, 
not  on  the  person  who  produced  it.  [PAi50.iGi02.sp102.Ni03] 

When  issues  arise  during  the  peer  review,  they  should  be 
communicated  to  the  primary  developer  of  the  work  product  for 

correction.  [PA150.IG102.SP102.N104] 

Refer  to  the  Project  Monitoring  and  Control  process  area  for  information 
about  tracking  issues  that  arise  during  a  peer  review. 

[PA1S0.IG102.SP102.N104.R101] 


Peer  reviews  should  address  the  following  guidelines:  there  must  be 
sufficient  preparation,  the  conduct  must  be  managed  and  controlled, 
consistent  and  sufficient  data  must  be  recorded  (an  example  is 
conducting  a  formal  inspection),  and  action  items  must  be  recorded. 

[PA150.IG102.SP102.N105] 

Typical  Work  Products 

1 .  Peer  review  results  [PAi50.iGi02.sp102.w10i] 

2.  Peer  review  issues  [PAi50.iGi02.sp102.w102] 

3.  Peer  review  data  [PAi50.iGi02.sp102.w103] 

Subpractices 

1 .  Perform  the  assigned  roles  in  the  peer  review.  [PAiso.iGio2.spio2.subPioi] 

2.  Identify  and  document  defects  and  other  issues  in  the  work 

prOdUCt.  [PA150.IG102.SP102.SubP102] 

3.  Record  the  results  of  the  peer  review,  including  the  action  items. 

[PA150.IG102.SP102.SubP103] 

4.  Collect  peer  review  data.  [PAi5o.iGio2.spio2.subPio4] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  on  data  collection.  [PAi50.iGi02.sp102.subPi04.Ri0i] 

5.  Identify  action  items  and  communicate  the  issues  to  relevant 
stakeholders.  [PAi5o.iGio2.spio2.subPios] 

6.  Conduct  an  additional  peer  review  if  the  defined  criteria  indicate  the 

need.  [PA150.IG102.SP102.SubP106] 

7.  Ensure  that  the  exit  criteria  for  the  peer  review  are  satisfied. 

[PA150.IG102.SP102.SubP107] 
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SP  2.3-2  Analyze  Peer  Review  Data 

Analyze  data  about  preparation,  conduct,  and  results  of  the  peer 

reviews.  [PA150.IG102.SP103] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 

information  about  obtaining  and  analyzing  data,  [paiso.igio2.spio3.rioi] 

Typical  Work  Products 

1 .  Peer  review  data  [PAi50.iGi02.sp103.w10i] 

2.  Peer  review  action  items  [paiso.igio2.spio3.wio2] 

Subpractices 

1 .  Record  data  related  to  the  preparation,  conduct,  and  results  of  the 
peer  reviews.  [PAiso.iGio2.spio3.subPioi] 

Typical  data  are  product  name,  product  size,  composition  of  the  peer  review  team, 
type  of  peer  review,  preparation  time  per  reviewer,  length  of  the  review  meeting, 
number  of  defects  found,  type  and  origin  of  defect,  etc.  Additional  information  on 
the  work  product  being  peer  reviewed  may  be  collected,  such  as  size, 
development  stage,  operating  modes  examined,  and  requirements  being 
evaluated.  [PAi50.iGio2.sp103.subPio1.Nioi] 

2.  Store  the  data  for  future  reference  and  analysis.  [PAiso.iGio2.spio3.subPio2] 

3.  Protect  the  data  to  ensure  that  peer  review  data  are  not  used 
inappropriately.  [PAi5o.iGio2.spio3.subPio3] 


Examples  of  inappropriate  use  of  peer  review  data  include  using  data  to  evaluate 
the  performance  of  people  and  using  data  for  attribution.  [PAi50.iGi02.sp103.subPi03.Ni0i] 


4.  Analyze  the  peer  review  data.  [PAi5o.iGio2.spio3.subPio4] 


SG  3  Verify  Selected  Work  Products 


Selected  work  products  are  verified  against  their  specified  requirements. 

[PA150.IG103] 


SP  3.1-1  Perform  Verification 

Perform  verification  on  the  selected  work  products,  [pai5o.igio3.spwi] 


Verifying  products  and  work  products  incrementally  promotes  early 
detection  of  problems  and  can  result  in  the  early  removal  of  defects. 
These  results  of  verification  save  considerable  cost  of  fault  isolation  and 
rework  associated  with  troubleshooting  problems,  [pai5o.igio3.spioi.nioi] 
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(For  users  of  the  continuous  representation,  this  is  a  capability  level  1 
specific  practice.  Verification  processes  at  capability  level  1  or  2  may 
not  include  procedures  and  criteria,  which  are  created  in  the  Establish 
Verification  Procedures  and  Criteria  specific  practice  at  capability  level 
3.  When  there  are  no  procedures  or  criteria  established,  use  the 
methods  established  by  the  Select  Work  Products  for  Verification 
specific  practice  to  accomplish  capability  level  1  performance.) 

[PA150.IG103.SP101.N102] 

Typical  Work  Products 

1.  Verification  results  [pai5o.igio3.spioi.wioi] 

2.  Verification  reports  [pai5o.igio3.spioi.wio2] 

3.  Demonstrations  [pai5o.igio3.spioi.wio3] 

4.  As-run  procedures  log  [paiso.igio3.spioi.wio4] 

Subpractices 

1 .  Perform  verification  of  selected  work  products  against  their 
requirements.  [PAiso.iGio3.spioi.subPio2] 

2.  Record  the  results  of  verification  activities.  [PAi5o.iGio3.spioi.subPio3] 

3.  Identify  action  items  resulting  from  verification  of  work  products. 

[PA150.IG103.SP101.SubP104] 

4.  Document  the  “as-run”  verification  method  and  the  deviations  from 
the  available  methods  and  procedures  discovered  during  its 
performance.  [PAiso.iGio3.spioi.subPios] 


SP  3.2-2  Analyze  Verification  Results  and  Identify  Corrective  Action 

Analyze  the  results  of  all  verification  activities  and  identify 
corrective  action.  ipaiso.igio3.spio2] 

Actual  results  must  be  compared  to  established  verification  criteria  to 
determine  acceptability,  [pai5o.igio3.spio2.nioi] 

The  results  of  the  analysis  are  recorded  as  evidence  that  verification 

was  conducted.  [PA150.IG103.SP102.N102] 
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For  each  work  product,  all  available  verification  results  are 
incrementally  analyzed  and  corrective  actions  are  initiated  to  ensure 
that  the  requirements  have  been  met.  Since  a  peer  review  is  one  of 
several  verification  methods,  peer  review  data  should  be  included  in  this 
analysis  activity  to  ensure  that  the  verification  results  are  analyzed 
sufficiently.  Analysis  reports  or  “as-run”  method  documentation  may 
also  indicate  that  bad  verification  results  are  due  to  method  problems, 
criteria  problems,  ora  verification  environment  problem. 

[PA150.IG103.SP102.N103] 


Refer  to  the  corrective  action  practices  of  Project  Monitoring  and 
Control  process  area  for  more  information  on  implementing  corrective 

action.  [PA1S0.IG103.SPW2.N103.R101] 

Typical  Work  Products 

1 .  Analysis  report  (such  as  statistics  on  performances,  causal 
analysis  of  nonconformances,  comparison  of  the  behavior  between 
the  real  product  and  models,  and  trends)  [pai5o.igio3spio2.wioi] 

2.  Trouble  reports  [paiso.igio3.spio2.wio2] 

3.  Change  requests  for  the  verification  methods,  criteria,  and 
environment  [paiso.igio3.spio2.wio3] 

4.  Corrective  actions  to  verification  methods,  criteria,  and/or 
environment  [PAi50.iGi03.sp102.w104] 

Subpractices 

1.  Compare  actual  results  to  expected  results.  [PAi5o.iGio3.spio2.subPioi] 

2.  Based  on  the  established  verification  criteria,  identify  products  that 
have  not  met  their  requirements  or  identify  problems  with  the 
methods,  procedures,  criteria,  and  verification  environment. 

[PA150.IG103.SP102.SubP102] 

3.  Analyze  the  verification  data  on  defects.  [PAi5o.iGio3.spio2.subPio3] 

4.  Record  all  results  of  the  analysis  in  a  report.  [PAi5o.iGio3.spio2.subPio4] 

5.  Use  verification  results  to  compare  actual  measurements  and 
performance  to  technical  performance  parameters. 

[PA150.IG103.SP102.SubP105] 

6.  Provide  information  on  how  defects  may  be  resolved  (including 
verification  methods,  criteria,  and  verification  environment)  and 
formalize  it  in  a  plan.  [PAi5o.iGio3.spio2.subPio6] 
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Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  verification  process  to  develop 
work  products  and  provide  services  to  achieve  the  specific  goals 
of  the  process  area.  pspi<ai 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  verification  process.  [gpio3i 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  verification  methods,  procedures,  criteria,  verification 
environment,  performing  peer  reviews,  and  verifying  selected  work 

products.  [PA150.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  verification 
process.  [gpio4] 

Elaboration: 

Typically,  this  plan  for  performing  the  verification  process  is  included  in 
(or  referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area,  [paiso.elkk] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  verification 
process,  developing  the  work  products,  and  providing  the  services 
of  the  process,  [gpiosj 
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Elaboration: 

Special  facilities  may  be  required  for  verifying  selected  work  products. 
When  necessary,  the  facilities  required  for  the  activities  in  the 
Verification  process  area  are  developed  or  purchased,  [paiso.elhoi 

Certain  verification  methods  may  require  special  tools,  equipment, 
facilities,  and  training  (e.g.,  peer  reviews  may  require  meeting  rooms 
and  trained  moderators;  certain  verification  tests  may  require  special 
test  equipment  and  people  skilled  in  the  use  of  the  equipment). 

[PA150.EL104] 


Examples  of  other  resources  provided  include  the  following  tools:  [paiso.elios] 

•  Test  management  tools 

•  Test-case  generators 

•  Test-coverage  analyzers 

•  Simulators 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
verification  process,  [gpiobi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  verification  process 
as  needed,  [g P1071 

Elaboration: 

Examples  of  training  topics  include  the  following:  [paiso.elios] 

•  Application  domain 

•  Verification  principles,  standards,  and  methods  (e.g.,  analysis,  demonstration, 
inspection,  test) 

•  Verification  tools  and  facilities 

•  Peer  review  preparation  and  procedures 

•  Meeting  facilitation 
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GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  verification  process  under 
appropriate  levels  of  configuration  management,  igpioq] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [paiso.elio6] 

•  Verification  procedures  and  criteria 

•  Peer  review  training  material 

•  Peer  review  data 

•  Verification  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  verification 
process  as  planned.  igpi24] 

Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process.  [paiso.elii3] 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai5o.elii4] 

•  Selecting  work  products  and  methods  for  verification 

•  Establishing  verification  procedures  and  criteria 

•  Conducting  peer  reviews 

•  Assessing  verification  results  and  identifying  corrective  action 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  verification  process  against  the  plan  for 
performing  the  process  and  take  appropriate  corrective  action. 

[G  P1 10] 
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Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA150.EL107] 

•  Verification  profile  (e.g.,  the  number  of  verifications  planned  and  performed,  and 
the  defects  found;  perhaps  categorized  by  verification  method  or  type) 

•  Number  of  defects  detected  by  defect  category 

•  Verification  problem  report  trends  (e.g.,  number  written  and  number  closed) 

•  Verification  problem  report  status  (i.e.,  how  long  each  problem  report  has  been 
open) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  verification  process  against 
its  process  description,  standards,  and  procedures,  and  address 
noncompliance,  [gphs] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [paiso.elios] 

•  Selecting  work  products  for  verification 

•  Establishing  and  maintaining  verification  procedures  and  criteria 

•  Performing  peer  reviews 

•  Verifying  selected  work  products 

Examples  of  work  products  reviewed  include  the  following:  [pai5o.elh2] 

•  Verification  procedures  and  criteria 

•  Peer  review  checklists 

•  Verification  reports 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  verification 
process  with  higher  level  management  and  resolve  issues.  igph2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 
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GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  verification 
process,  [gpiuj 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  verification  process  to  support  the  future  use  and 
improvement  of  the  organization’s  processes  and  process  assets. 

[G  P1 17] 

GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  verification 
process  that  address  quality  and  process  performance  based  on 
customer  needs  and  business  objectives,  [gpiwi 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  verification  process  to  achieve  the 
established  quantitative  quality  and  process-performance 
objectives,  [gpubj 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  verification  process  in 
fulfilling  the  relevant  business  objectives  of  the  organization.  igpi25] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  verification  process.  [GP1211 
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VALIDATION 

Engineering 


Purpose 


The  purpose  of  Validation  is  to  demonstrate  that  a  product  or  product 
component  fulfills  its  intended  use  when  placed  in  its  intended 
environment.  [pau9] 


Introductory  Notes 


Validation  activities  can  be  applied  to  all  aspects  of  the  product  in  any  of 
its  intended  environments,  such  as  operation,  training,  manufacturing, 
maintenance,  and  support  services.  The  methods  employed  to 
accomplish  validation  can  be  applied  to  work  products  as  well  as  to  the 
product  and  product  components.  The  work  products  (e.g., 
requirements,  designs,  prototypes)  should  be  selected  on  the  basis  of 
which  are  the  best  predictors  of  how  well  the  product  and  product 
component  will  satisfy  user  needs.  [pai49.nio5] 

The  validation  environment  should  represent  the  intended  environment 
for  the  product  and  product  components  as  well  as  represent  the 
intended  environment  suitable  for  validation  activities  with  work 

products.  [PA149.N106] 

Validation  demonstrates  that  the  product,  as  provided,  will  fulfill  its 
intended  use;  whereas,  verification  addresses  whether  the  work  product 
properly  reflects  the  specified  requirements.  In  other  words,  verification 
ensures  that  “you  built  it  right;”  whereas,  validation  ensures  that  “you 
built  the  right  thing.”  Validation  activities  use  approaches  similar  to 
verification  (e.g.,  test,  analysis,  inspection,  demonstration,  or 
simulation).  Often,  the  end  users  are  involved  in  the  validation  activities. 
Both  validation  and  verification  activities  often  run  concurrently  and  may 
use  portions  of  the  same  environment.  [PA149.N102] 

Refer  to  the  Verification  process  area  for  more  information  about 
verification  activities,  pau9.nio2.rioi] 

Where  possible,  validation  should  be  accomplished  using  the  product  or 
product  component  operating  in  its  intended  environment.  The  entire 
environment  may  be  used  or  only  part  of  it.  However,  validation  issues 
can  be  discovered  early  in  the  life  of  the  project  using  work  products. 

[PA149.N103] 
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When  validation  issues  are  identified,  they  are  referred  to  the  processes 
associated  with  the  Requirements  Development,  Technical  Solution,  or 
Project  Monitoring  and  Control  process  areas  for  resolution.  [pai49.nio4] 

The  specific  practices  of  this  process  area  build  on  each  other  in  the 
following  way.  The  Select  Products  for  Validation  specific  practice 
enables  the  identification  of  the  product  or  product  component  to  be 
validated  and  the  methods  to  be  used  to  perform  the  validation.  The 
Establish  the  Validation  Environment  specific  practice  enables  the 
determination  of  the  environment  that  will  be  used  to  carry  out  the 
validation.  The  Establish  Validation  Procedures  and  Criteria  specific 
practice  enables  the  development  of  validation  procedures  and  criteria 
that  are  aligned  with  the  characteristics  of  selected  products,  customer 
constraints  on  validation,  methods,  and  the  validation  environment.  The 
Perform  Validation  specific  practice  enables  the  performance  of 
validation  according  to  the  methods,  procedures,  and  criteria,  [pausnw] 


Related  Process  Areas 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  requirements  validation.  ipau9.rioii 

Refer  to  the  Technical  Solution  process  area  for  more  information  about 
transforming  requirements  into  product  specifications  and  for  corrective 
action  when  validation  issues  are  identified  that  affect  the  product  or 
product-component  design.  [PA149.R102} 

Refer  to  the  Verification  process  area  for  more  information  about 
verifying  that  the  product  or  product  component  meets  its  requirements. 

[PA149.R103] 


Specific  Goals 


SG  1 

Prepare  for  Validation  [pai49 .igioi] 

Preparation  for  validation  is  conducted. 

SG2 

Validate  Product  or  Product  Components  [PA1491G102] 

The  product  or  product  components  are  validated  to  ensure  that  they  are 
suitable  for  use  in  their  intended  operating  environment. 
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Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [cuoe.Guoi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Prepare  for  Validation  [pai49.igioi] 

SP  1.1-1  Select  Products  for  Validation 

SP  1.2-2  Establish  the  Validation  Environment 

SP  1.3-3  Establish  Validation  Procedures  and  Criteria 

SG  2  Validate  Product  or  Product  Components  [pah9.igio2] 

SP  2. 1  -1  Perform  Validation 

SP  2.2-1  Analyze  Validation  Results 

GG  1  Achieve  Specific  Goals  [clkk.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 
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GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clim.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioii 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Prepare  for  Validation 


Preparation  for  validation  is  conducted.  [pau9.igioi] 

Preparation  activities  include  selecting  products  and  product 
components  for  validation  and  establishing  and  maintaining  the 
validation  environment,  procedures,  and  criteria.  The  items  selected  for 
validation  may  include  only  the  product  or  it  may  include  appropriate 
levels  of  the  product  components  that  are  used  to  build  the  product.  Any 
product  or  product  component  may  be  subject  to  validation,  including 
replacement,  maintenance,  and  training  products,  to  name  a  few. 

[PA149.IG101.N101] 


The  environment  required  to  validate  the  product  or  product  component 
is  prepared.  The  environment  may  be  purchased  or  may  be  specified, 
designed,  and  built.  The  environments  used  for  product  integration  and 
verification  may  be  considered  in  collaboration  with  the  validation 
environment  to  reduce  cost  and  improve  efficiency  or  productivity. 

[PA149.IG101.N102] 


SP  1.1-1  Select  Products  for  Validation 

Select  products  and  product  components  to  be  validated  and  the 
validation  methods  that  will  be  used  for  each,  [paus.igioi.spioi] 


Products  and  product  components  are  selected  for  validation  on  the 
basis  of  their  relationship  to  user  needs.  For  each  product  component, 
the  scope  of  the  validation  (e.g.,  operational  behavior,  maintenance, 
training,  and  user  interface)  should  be  determined,  [pai49.igioi  spioi.nio4] 
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The  requirements  and  constraints  for  performing  validation  are 
collected.  Then,  validation  methods  are  selected  based  on  their  ability 
to  demonstrate  that  user  needs  are  satisfied.  The  validation  methods 
not  only  define  the  technical  approach  to  product  validation,  but  also 
drive  the  needs  for  the  facilities,  equipment,  and  environments.  This 
may  result  in  the  generation  of  lower  level  product-component 
requirements  that  are  handled  by  the  requirements  development 
processes.  Derived  requirements,  such  as  interface  requirements  to 
test  sets  and  test  equipment,  may  be  generated.  These  requirements 
are  also  passed  to  the  requirements  development  processes  to  ensure 
that  the  product  or  product  components  can  be  validated  in  an 
environment  that  supports  the  methods,  [pai49.igioi.spioi.nioi] 

Validation  methods  should  be  selected  early  in  the  life  of  the  project  so 
they  are  clearly  understood  and  agreed  to  by  the  relevant  stakeholders. 

[PA149.IG101.SP101.N102] 


The  validation  methods  address  the  development,  maintenance, 
support,  and  training  for  the  product  or  product  component  as 
appropriate,  [pai49.igioi.spioi.nio3] 

Typical  Work  Products 

1 .  Lists  of  products  and  product  components  selected  for  validation 

[PA149.IG101.SP101.W101] 

2.  Validation  methods  for  each  product  or  product  component 

[PA149.IG101.SP101.W102] 

3.  Requirements  for  performing  validation  for  each  product  or  product 

component  [PAi49.IGIOI.SPIOI.WIO3] 

4.  Validation  constraints  for  each  product  or  product  component 

[PA149.IG101.SP101.W104] 

Subpractices 

1 .  Identify  the  key  principles,  features,  and  phases  for  product  or 
product-component  validation  throughout  the  life  of  the  project. 

[PA149.IG101.SP101.SubP101] 

2.  Determine  which  categories  of  user  needs  (operational, 
maintenance,  training,  or  support)  are  to  be  validated. 

[PA149.IG101.SP101.SubP102] 

The  product  or  product  component  must  be  maintainable  and  supportable  in  its 
intended  operational  environment.  This  specific  practice  also  addresses  the  actual 
maintenance,  training,  and  support  services  that  may  be  delivered  along  with  the 

prOdUCt.  [PA149.IG101.SP101.SubP102.N101] 
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An  example  of  evaluation  of  maintenance  concepts  in  the  operational  environment 
is  a  demonstration  that  maintenance  tools  are  operating  with  the  actual  product. 

[PA149.IG101.SP101.SubP102.N102] 


3.  Select  the  product  and  product  components  to  be  validated. 

[PA149.IG101.SP101.SubP105] 

4.  Select  the  evaluation  methods  for  product  or  product-component 
validation.  [PAi49.iGioi.spioi.subPio3] 

5.  Review  the  validation  selection,  constraints,  and  methods  with 
relevant  stakeholders.  [PAi49.iGioi.spioi.subPio4] 


SP  1.2-2  Establish  the  Validation  Environment 

Establish  and  maintain  the  environment  needed  to  support 
validation.  [pau9.igioi.spio2] 


The  requirements  for  the  validation  environment  are  driven  by  the 
product  or  product  components  selected,  by  the  type  of  the  work 
products  (e.g.,  design,  prototype,  final  version),  and  by  the  methods  of 
validation.  These  may  yield  requirements  for  the  purchase  or 
development  of  equipment,  software,  or  other  resources.  These 
requirements  are  provided  to  the  requirements  development  processes 
for  development.  The  validation  environment  may  include  the  reuse  of 
existing  resources.  In  this  case,  arrangements  for  the  use  of  these 
resources  must  be  made.  Examples  of  the  type  of  elements  in  a 
validation  environment  include  the  following:  [pai49.igioi.spio2.nioi] 

•  Test  tools  interfaced  with  the  product  being  validated  (e.g.,  scope, 
electronic  devices,  probes) 

•  Temporary  embedded  test  software 

•  Recording  tools  for  dump  or  further  analysis  and  replay 

•  Simulated  subsystems  or  components  (by  software,  electronics,  or 
mechanics) 

•  Simulated  interfaced  systems  (e.g.,  a  dummy  warship  for  testing  a 
naval  radar) 

•  Real  interfaced  systems  (e.g.,  aircraft  for  testing  a  radar  with 
trajectory  tracking  facilities) 

•  Facilities  and  customer-supplied  products 

•  The  skilled  people  to  operate  or  use  all  the  above  elements 

•  Dedicated  computing  or  network  test  environment  (e.g.,  pseudo- 
operational  telecommunications-network  testbed  or  facility  with 
actual  trunks,  switches,  and  systems  established  for  realistic 
integration  and  validation  trials) 
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Early  selection  of  the  products  or  product  components  to  be  validated, 
the  work  products  to  be  used  in  the  validation,  and  the  validation 
methods  is  needed  to  ensure  that  the  validation  environment  will  be 
available  when  necessary,  [pai49.igioi.spio2.nio2] 

The  validation  environment  should  be  carefully  controlled  to  provide  for 
replication,  analysis  of  results,  and  re-validation  of  problem  areas. 

[PA149.IG101.SP102.N103] 

Typical  Work  Products 

1.  Validation  environment  [pai49.igioi.spio2.wioi] 

Subpractices 

1 .  Identify  validation  environment  requirements.  [PAi49.iGioi.spio2.subPioi] 

2.  Identify  customer-supplied  products.  [PAi49.iGioi.spio2.subPio2] 

3.  Identify  reuse  items.  [PAi49.iGioi.spio2.subPio3] 

4.  Identify  test  equipment  and  tools.  [PAi49.iGioi.spio2.subPio4] 

5.  Identify  validation  resources  that  are  available  for  reuse  and 
mod ification.  [pah9.igioi  spio2.subPio5] 

6.  Plan  the  availability  of  resources  in  detail.  [PAi49.iGioi.spio2.subPioe] 


SP  1.3-3  Establish  Validation  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  validation. 

[PA149.IG101.SP103] 

Validation  procedures  and  criteria  are  defined  to  ensure  that  the  product 
or  product  component  will  fulfill  its  intended  use  when  placed  in  its 
intended  environment.  Acceptance  test  cases  and  procedures  may 
meet  the  need  for  validation  procedures,  [pai49.igioi.spio3.nioi] 

The  validation  procedures  and  criteria  include  test  and  evaluation  of 
maintenance,  training,  and  support  services,  [pai49.igioi.spio3.nio2] 

Examples  of  sources  for  validation  criteria  include  the  following:  [pai49.igioi.spio3.nio3] 

•  Product  and  product-component  requirements 

•  Standards 

•  Customer  acceptance  criteria 

•  Environmental  performance 

•  Thresholds  of  performance  deviation 
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Typical  Work  Products 

1 .  Validation  procedures  [pai49.igioi.spio3.wioi] 

2.  Validation  criteria  [PAi49.iGi01.sp103.w102] 

3.  Test  and  evaluation  procedures  for  maintenance,  training,  and 

SUppOrt  [PA149.IG101.SP103.W103] 

Subpractices 

1 .  Review  the  product  requirements  to  ensure  that  issues  affecting 
validation  of  the  product  or  product  component  are  identified  and 
resolved.  [PAi49.iGioi.spio3.subPioi] 

2.  Document  the  environment,  operational  scenario,  procedures, 
inputs,  outputs,  and  criteria  for  the  validation  of  the  selected 
product  or  product  component.  [PAi49.iGioi.spio3.subPio2j 

3.  Assess  the  design  as  it  matures  in  the  context  of  the  validation 
environment  to  identify  validation  issues.  [PAi49.iGioi.spio3.subPio3] 


SG  2  Validate  Product  or  Product  Components 


The  product  or  product  components  are  validated  to  ensure  that  they  are 
suitable  for  use  in  their  intended  operating  environment.  [pau9.igio2] 

The  validation  methods,  procedures,  and  criteria  are  used  to  validate 
the  selected  products  and  product  components  and  any  associated 
maintenance,  training,  and  support  services  using  the  appropriate 
validation  environment,  [pai49.igio2.nio2] 


SP  2.1-1  Perform  Validation 

Perform  validation  on  the  selected  products  and  product 
components.  [pau9.igio2.spioi] 


To  be  acceptable  to  users,  a  product  or  product  component  must 
perform  as  expected  in  its  intended  operational  environment. 

[PA149.IG102.SP101.N101] 


Validation  activities  are  performed  and  the  resulting  data  are  collected 
according  to  the  established  methods,  procedures,  and  criteria. 

[PA149.IG102.SP101.N102] 


The  as-run  validation  procedures  should  be  documented  and  the 
deviations  occurring  during  the  execution  should  be  noted,  as 
appropriate,  [pai49.igio2.spioi.nio3] 
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(For  users  of  the  continuous  representation,  this  is  a  capability  level  1 
specific  practice.  Validation  processes  at  capability  level  1  or  2  may  not 
include  procedures  and  criteria,  which  are  created  in  the  Establish 
Validation  Procedures  and  Criteria  specific  practice  at  capability  level  3. 
When  there  are  no  procedures  or  criteria  established,  use  the  methods 
established  by  the  Select  Products  for  Validation  specific  practice  to 
accomplish  capability  level  1  performance.)  [pai49.igio2.spioi.nio4] 

Typical  Work  Products 

1.  Validation  reports  [pai49.igio2.spioi.wioi] 

2.  Validation  results  [PAi49.iGi02.sp101.w102] 

3.  Validation  cross-reference  matrix  [pah9.igio2.spioi.wio3] 

4.  As-run  procedures  log  [pah9.igio2.spioi.wio4] 

5.  Operational  demonstrations  [pah9.igio2.spioi.wio5] 


SP  2.2-1  Analyze  Validation  Results 

Analyze  the  results  of  the  validation  activities  and  identify  issues. 

[ PA149.IG102.SP102 ] 


The  data  resulting  from  validation  tests,  inspections,  demonstrations,  or 
evaluations  are  analyzed  against  the  defined  validation  criteria.  Analysis 
reports  indicate  whether  the  needs  were  met;  in  the  case  of 
deficiencies,  these  reports  document  the  degree  of  success  or  failure 
and  categorize  probable  cause  of  failure.  The  collected  test,  inspection, 
or  review  results  are  compared  with  established  evaluation  criteria  to 
determine  whether  to  proceed  or  to  address  requirements  or  design 
issues  in  the  requirements  development  or  technical  solution 

processes.  [PAH9.IG102.SP102.N101] 


Analysis  reports  or  as-run  validation  documentation  may  also  indicate 
that  bad  test  results  are  due  to  a  validation  procedure  problem  or  a 
validation  environment  problem,  [pah9.igio2.spio2.nio2] 

Typical  Work  Products 

1 .  Validation  deficiency  reports  [pah9.igio2.spio2.wioi] 

2.  Validation  issues  [pah9.igio2.spio2.wio2] 

3.  Procedure  change  request  [pah9.igio2.spio2.wio3] 

Subpractices 

1.  Compare  actual  results  to  expected  results.  [PAH9.iGio2.spio2.subPioi] 
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2.  Based  on  the  established  validation  criteria,  identify  products  and 
product  components  that  do  not  perform  suitably  in  their  intended 
operating  environments,  or  identify  problems  with  the  methods, 
criteria,  and/or  environment.  [PAi49.iGio2.spio2.subPio2] 

3.  Analyze  the  validation  data  for  defects.  [PAi49.iGio2.spio2.subPio3] 

4.  Record  the  results  of  the  analysis  and  identify  issues. 

[PA149.IG102.SP102.SubP104] 

5.  Use  validation  results  to  compare  actual  measurements  and 
performance  to  intended  use  or  operational  need. 

[PA149.IG102.SP102.SubP105] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  validation  process  to  develop 
work  products  and  provide  services  to  achieve  the  specific  goals 
of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  validation  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  selecting 
products  and  product  components  for  validation;  for  selecting  validation 
methods;  and  for  establishing  and  maintaining  validation  procedures, 
criteria,  and  environments  that  ensure  the  products  and  product 
components  satisfy  user  needs  in  their  intended  operating  environment. 

[PA149.EL101] 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  validation 
process.  [gpio4} 

Elaboration: 

Typically,  this  plan  for  performing  the  validation  process  is  included  in 
(or  referenced  by)  the  project  plan,  which  is  described  in  the  Project 
Planning  process  area.  [pai49.elh6] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  validation  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process,  [gpiosi 

Elaboration: 

Special  facilities  may  be  required  for  validating  the  product  or  product 
components.  When  necessary,  the  facilities  required  for  validation  are 
developed  or  purchased.  [pai49.elih] 

Examples  of  other  resources  provided  include  the  following  tools:  [pam9.elio3] 

•  Test  management  tools 

•  Test-case  generators 

•  Test-coverage  analyzers 

•  Simulators 

•  Load,  stress,  and  performance  tools 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
validation  process,  [gpiobi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  validation  process 
as  needed.  [gpio7] 


Engineering,  Validation 


439 


CMMI-SW,  vl.1 
Continuous  Representation 

Elaboration: 

Examples  of  training  topics  include  the  following:  [pai49.elio4] 

•  Application  domain 

•  Validation  principles,  standards,  and  methods 

•  Intended-use  environment 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  validation  process  under 
appropriate  levels  of  configuration  management,  igpioq] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai49.elios] 

•  Lists  of  products  and  product  components  selected  for  validation 

•  Validation  methods,  procedures,  and  criteria 

•  Validation  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  validation 
process  as  planned.  [gpi24] 


Elaboration: 

Select  relevant  stakeholders  from  customers,  end  users,  developers, 
producers,  testers,  suppliers,  marketers,  maintainers,  disposal 
personnel,  and  others  who  may  be  affected  by,  or  may  affect,  the 
product  as  well  as  the  process.  [pai49.elh3] 


Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai49.elh4] 

•  Selecting  the  products  and  product  components  to  be  validated 

•  Establishing  the  validation  methods,  procedures,  and  criteria 

•  Reviewing  results  of  product  and  product-component  validation  and  resolving 
issues 

•  Resolving  issues  with  the  customers  or  end  users 


Issues  with  the  customers  or  end  users  are  resolved  particularly  when 
there  are  significant  deviations  from  their  baseline  needs  for  the 
following:  [pai49.elh5] 
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•  Waivers  on  the  contract  or  agreement  (what,  when,  and  for  which 
products,  services,  or  manufactured  products) 

•  Additional  in-depth  studies,  trials,  tests,  or  evaluations 

•  Possible  changes  in  the  contracts  or  agreements 

GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  validation  process  against  the  plan  for 
performing  the  process  and  take  appropriate  corrective  action. 

[G  P1 10] 

Elaboration: 

Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA149.EL109] 

•  Number  of  validation  activities  completed  (planned  versus  actual) 

•  Validation  problem  report  trends  (e.g.,  number  written  and  number  closed) 

•  Validation  problem  report  aging  (i.e,,  how  long  each  problem  report  has  been 
open) 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  validation  process  against 
its  process  description,  standards,  and  procedures,  and  address 
noncompliance.  igph3i 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai49.elho] 

•  Selecting  the  products  and  product  components  to  be  validated 

•  Establishing  and  maintaining  validation  methods,  procedures,  and  criteria 

•  Validating  products  or  product  components 

Examples  of  work  products  reviewed  include  the  following:  [pai49.elh2] 

•  Validation  methods,  procedures,  and  criteria 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  validation  process 
with  higher  level  management  and  resolve  issues.  [GP1121 


Engineering,  Validation 


441 


CMMI-SW,  vl.1 
Continuous  Representation 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  validation 
process,  igpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  validation  process  to  support  the  future  use  and  improvement 
of  the  organization’s  processes  and  process  assets.  [gpu7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the  validation 
process  that  address  quality  and  process  performance  based  on 
customer  needs  and  business  objectives,  [gpubj 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  validation  process  to  achieve  the 
established  quantitative  quality  and  process-performance 
objectives,  [gpu® 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  validation  process  in 
fulfilling  the  relevant  business  objectives  of  the  organization.  [gpi25] 
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GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  validation  process.  [GP121] 
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SUPPORT _ 

The  following  section  contains  all  of  the  process  areas  that  belong  to 
the  Support  process  area  category.  The  Support  process  areas  of 
CMMI  are  as  follows:  [fmw.tkk] 

•  Configuration  Management 

•  Process  and  Product  Quality  Assurance 

•  Measurement  and  Analysis 

•  Decision  Analysis  and  Resolution 

•  Causal  Analysis  and  Resolution 

See  Chapter  5  for  more  information  about  the  Support  process  areas 
and  how  they  interact,  [fmw.tkb] 
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CONFIGURATION  MANAGEMENT 

Support 


Purpose 


The  purpose  of  Configuration  Management  is  to  establish  and  maintain 
the  integrity  of  work  products  using  configuration  identification, 
configuration  control,  configuration  status  accounting,  and  configuration 
audits.  [PA159] 


Introductory  Notes 


The  Configuration  Management  process  area  involves  the  following: 

[PA159.N101] 

•  Identifying  the  configuration  of  selected  work  products  that 
compose  the  baselines  at  given  points  in  time 

•  Controlling  changes  to  configuration  items 

•  Building  or  providing  specifications  to  build  work  products  from  the 
configuration  management  system 

•  Maintaining  the  integrity  of  baselines 

•  Providing  accurate  status  and  current  configuration  data  to 
developers,  end  users,  and  customers 

The  work  products  placed  under  configuration  management  include  the 
products  that  are  delivered  to  the  customer,  designated  internal  work 
products,  acquired  products,  tools,  and  other  items  that  are  used  in 
creating  and  describing  these  work  products.  See  the  definition  of 
“configuration  management”  in  Appendix  C,  the  glossary.  [PA159.N102] 
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Examples  of  work  products  that  may  be  placed  under  configuration  management 
include  the  following:  [pais9.nio9] 

•  Plans 

•  Process  descriptions 

•  Requirements 

•  Design  data 

•  Drawings 

•  Product  specifications 

•  Code 

•  Compilers 

•  Product  data  files 

•  Product  technical  publications 


Configuration  management  of  work  products  may  be  performed  at 
several  levels  of  granularity.  See  the  definition  of  “configuration  item”  in 
Appendix  C,  the  glossary.  Configuration  items  can  be  decomposed  into 
configuration  components  and  configuration  units.  Only  the  term 
“configuration  item”  is  used  in  this  process  area.  Therefore,  in  these 
practices,  “configuration  item”  may  be  interpreted  as  “configuration 
component”  or  “configuration  unit”  as  appropriate.  [PA159.N103] 

Baselines  provide  a  stable  basis  for  continuing  evolution  of 
configuration  items.  See  the  definition  of  “baseline”  in  Appendix  C,  the 
glossary.  [pais9.nio4] 


An  example  of  a  baseline  is  an  approved  description  of  a  product  that  includes 
internally  consistent  versions  of  requirements,  requirement  traceability  matrices,  design, 
discipline-specific  items,  and  end-user  documentation,  [paiss.nuo] 


Baselines  are  added  to  the  configuration  management  system  as  they 
are  developed.  Changes  to  baselines  and  the  release  of  work  products 
built  from  the  configuration  management  system  are  systematically 
controlled  and  monitored  via  the  configuration  control,  change 
management,  and  configuration  auditing  functions  of  configuration 
management.  [pais9.nio5] 

This  process  area  applies  not  only  to  configuration  management  on 
projects,  but  also  to  configuration  management  on  organization  work 
products  such  as  standards,  procedures,  and  reuse  libraries.  [pai59.nio6] 

Configuration  management  is  focused  on  the  rigorous  control  of  the 
managerial  and  technical  aspects  of  work  products,  including  the 
delivered  system.  [PA159.N107] 
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This  process  area  covers  the  practices  for  performing  the  configuration 
management  function  and  is  applicable  to  all  work  products  that  are 
placed  under  configuration  management,  [paiss  nios] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  information  on 
developing  plans  and  work  breakdown  structures,  which  may  be  useful 
for  determining  configuration  items.  ipais9.rioii 

Refer  to  the  Causal  Analysis  and  Resolution  process  area  for  more 
information  about  both  the  method  to  use  for  analyzing  the  impact  of 
change  requests  and  the  method  to  use  when  evaluating  changes. 

[PA159.R102] 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  performance  analyses  and  corrective  actions. 

[PA159.R103] 


Specific  Goals 


SG  1  Establish  Baselines  ipais9igioi] 


Baselines  of  identified  work  products  are  established. 


SG  2  Track  and  Control  Changes  [PA159.1G102] 


Changes  to  the  work  products  under  configuration  management  are  tracked 
and  controlled. 


SG  3  Establish  Integrity  [PA159.IG103] 


Integrity  of  baselines  is  established  and  maintained. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 


The  process  is  institutionalized  as  a  managed  process. 
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GG  3  Institutionalize  a  Defined  Process  [clkm.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 


SG  1  Establish  Baselines  [paiss.igioi] 


SP  1.1-1 

Identify  Configuration  Items 

SP  1.2-1 

Establish  a  Configuration  Management  System 

SP  1.3-1 

Create  or  Release  Baselines 

SG  2  Track  and  Control  Changes  [pais9.igio2] 

SP  2.1-1 

Track  Change  Requests 

SP  2.2-1 

Control  Configuration  Items 

SG  3  Establish  Integrity  [pais9.igio3] 

SP  3.1-1 

Establish  Configuration  Management  Records 

SP  3.2-1 

Perform  Configuration  Audits 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [clio3.glioi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clkm.glioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [cliosglioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clioo.glioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 
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GP  5.2  Correct  Root  Causes  of  Problems 


Specific  Practices  by  Goal 


SG  1  Establish  Baselines 


Baselines  of  identified  work  products  are  established.  [pai59.igiov 

Specific  practices  to  establish  baselines  are  covered  by  this  specific 
goal.  The  specific  practices  under  the  Track  and  Control  Changes 
specific  goal  serve  to  maintain  the  baselines.  The  specific  practices  of 
the  Establish  Integrity  specific  goal  document  and  audit  the  integrity  of 
the  baselines,  [pai59.igioi.nioi] 


SP  1.1-1  Identify  Configuration  Items 

Identify  the  configuration  items,  components,  and  related  work 
products  that  will  be  placed  under  configuration  management. 

[PA159.IG101  .SP101] 


Configuration  identification  is  the  selection,  creation,  and  specification 
of  the  following:  [pai59.igioi.spioi.nioi] 

•  Products  that  are  delivered  to  the  customer 

•  Designated  internal  work  products 

•  Acquired  products 

•  Tools 

•  Other  items  that  are  used  in  creating  and  describing  these  work 
products 

Items  under  configuration  management  will  include  specifications  and 
interface  documents  that  define  the  requirements  for  the  product.  Other 
documents,  such  as  test  results,  may  also  be  included,  depending  on 
their  criticality  to  defining  the  product,  [pai59.igioi.spioi.nio4] 

A  “configuration  item”  is  an  entity  designated  for  configuration 
management,  which  may  consist  of  multiple  related  work  products  that 
form  a  baseline.  This  logical  grouping  provides  ease  of  identification 
and  controlled  access.  The  selection  of  work  products  for  configuration 
management  should  be  based  on  criteria  established  during  planning. 

[PA159.IG101.SP101.N102] 
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Configuration  items  can  be  decomposed  into  configuration  components 
and  configuration  units.  Only  the  term  “configuration  item”  is  used  in  this 
process  area.  In  these  practices,  “configuration  item”  may  be 
interpreted  as  “configuration  component”  or  “configuration  unit”  as 
appropriate.  For  example,  configuration  items  in  the  area  of 
requirements  management  could  vary  from  each  individual  requirement 
to  a  set  of  requirements,  [pai59.igioi.spioi.nio3] 

Typical  Work  Products 

1.  Identified  configuration  items  [pai59.igioi.spioi.wioi] 

Subpractices 

1 .  Select  the  configuration  items  and  the  work  products  that  compose 
them  based  on  documented  criteria.  [PAi59.iGioi.spioi.subPioi] 


Example  criteria  for  selecting  configuration  items  at  the  appropriate  work  product 
level  include  the  following:  [PAi59.iGi01.sp101.subPi01.Ni02] 

•  Work  products  that  may  be  used  by  two  or  more  groups 

•  Work  products  that  are  expected  to  change  over  time  either  because  of  errors  or 
change  of  requirements 

•  Work  products  that  are  dependent  on  each  other  in  that  a  change  in  one 
mandates  a  change  in  the  others 

•  Work  products  that  are  critical  for  the  project 


Examples  of  work  products  that  may  be  part  of  a  configuration  item  include  the 
following:  [PAi59.iGi01.sp101.subPi01.Ni0i] 

•  Process  descriptions 

•  Requirements 

•  Design 

•  Test  plans  and  procedures 

•  Test  results 

•  Interface  descriptions 


For  Software  Engineering 

Examples  of  software  work  products  that  may  be  part  of  a  configuration  item 
include  the  following:  iPAi59.iGioi.spioi.subPioi.Nioi.AMPioii 

•  Code/module 

•  Tools  (e.g.,  compilers) 

2.  Assign  unique  identifiers  to  configuration  items.  [PAisg.iGioi.spioi.subPiog 

3.  Specify  the  important  characteristics  of  each  configuration  item. 

[PA159.IG101.SP101.SubP103] 
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Example  characteristics  of  configuration  items  include  author,  document  or  file 
type,  and  programming  language  for  software  code  files.  [PAi59.iGi01.sp101.subPi03.Ni0i] 


4.  Specify  when  each  configuration  item  is  placed  under  configuration 
management.  [PAi59.iGioi.spioi.subPio4] 

Example  criteria  for  determining  when  to  place  work  products  under  configuration 
management  include  the  following:  [PAi59.iGi01.sp101.subPi04.Ni0i] 

•  Stage  of  the  project  life  cycle 

•  When  the  work  product  is  ready  for  test 

•  Degree  of  control  desired  on  the  work  product 

•  Cost  and  schedule  limitations 

•  Customer  requirements 

5.  Identify  the  owner  responsible  for  each  configuration  item. 

[PA159.IG101.SP101.SubP105] 


SP  1.2-1  Establish  a  Configuration  Management  System 

Establish  and  maintain  a  configuration  management  and  change 
management  system  for  controlling  work  products,  [pais9.igwi.spw2] 


A  configuration  management  system  includes  the  storage  media,  the 
procedures,  and  the  tools  for  accessing  the  configuration  system. 

[PA159.1G101.SP102.N101] 

A  change  management  system  includes  the  storage  media,  the 
procedures,  and  tools  for  recording  and  accessing  change  requests. 

[PA159.IG101.SP102.N102] 

Typical  Work  Products 

1 .  Configuration  management  system  with  controlled  work  products 

[PA159.IG101.SP102.W101] 

2.  Configuration  management  system  access  control  procedures 

[PA159.IG101.SP102.W102] 

3.  Change  request  database  [PAi59.iGi01sp102.w103] 

Subpractices 

1.  Establish  a  mechanism  to  manage  multiple  control  levels  of 
configuration  management.  [PAi59.iGioi.spio2.subPioi] 
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Examples  of  situations  leading  to  multiple  levels  of  control  include  the  following: 

[PA159.IG101.SP102.SubP101.N101] 

•  Differences  in  the  levels  of  control  needed  at  different  times  in  the  project  life  cycle 
(e.g.,  tighter  control  as  product  matures) 

•  Differences  in  the  levels  of  control  needed  for  different  types  of  systems  (e.g., 
software-only  systems  versus  systems  that  include  hardware  and  software) 

•  Differences  in  the  levels  of  control  needed  to  satisfy  privacy  and  security 
requirements  for  the  configuration  items 


2.  Store  and  retrieve  configuration  items  in  the  configuration 

management  system.  [PAi59.iGioi.spio2.subPio2] 

Examples  of  configuration  management  systems  include  the  following: 

[PA159.IG101.SP102.SubP102.N101] 

•  Dynamic  (or  developer’s)  systems  contain  components  currently  being  created  or 
revised.  They  are  in  the  developer's  workspace  and  are  controlled  by  the 
developer.  Configuration  items  in  a  dynamic  system  are  under  version  control. 

•  Master  (or  controlled)  systems  contain  current  baselines  and  changes  to  them. 
Configuration  items  in  a  master  system  are  under  full  configuration  management 
as  described  in  this  process  area. 

•  Static  systems  contain  archives  of  various  baselines  released  for  use.  Static 
systems  are  under  full  configuration  management  as  described  in  this  process 
area. 

3.  Share  and  transfer  configuration  items  between  control  levels 

within  the  configuration  management  system.  [PAi59.iGioi.spio2.subPio3] 

4.  Store  and  recover  archived  versions  of  configuration  items. 

[PA159.IG101.SP102.SubP104] 

5.  Store,  update,  and  retrieve  configuration  management  records. 

[PA159.IG101.SP102.SubP105] 

6.  Create  configuration  management  reports  from  the  configuration 

management  system.  [PAi59.iGioi.spio2.subPio6] 

7.  Preserve  the  contents  of  the  configuration  management  system. 

[PA159.IG101.SP102.SubP107] 


Examples  of  preservation  functions  of  the  configuration  management  system 
include  the  following:  [PAi59.iGi01.sp102.subPi07.Ni0i] 

•  Backups  and  restoration  of  configuration  management  files 

•  Archiving  of  configuration  management  files 

•  Recovery  from  configuration  management  errors 

8.  Revise  the  configuration  management  structure  as  necessary. 

[PA159.]G101.SP102.SubP108] 
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SP  1.3-1  Create  or  Release  Baselines 

Create  or  release  baselines  for  internal  use  and  for  delivery  to  the 

CUStOmer.  [PA1S9.IG101.SPW3] 


A  baseline  is  a  set  of  specifications  or  work  products  that  has  been 
formally  reviewed  and  agreed  upon,  that  thereafter  serves  as  the  basis 
for  further  development,  and  that  can  be  changed  only  through  change 
control  procedures.  A  baseline  represents  the  assignment  of  an 
identifier  to  a  configuration  item  and  its  associated  entities. 

[PA159.IG101.SP103.N101] 

For  Software  Engineering 

A  set  of  reguirements,  design,  source  code  files  and  the 
associated  executable  code,  build  files,  and  user 
documentation  (associated  entities)  that  have  been  assigned 
a  unigue  identifier  can  be  considered  to  be  a  baseline. 
Release  of  a  baseline  constitutes  retrieval  of  source  code  files 
(configuration  items)  from  the  configuration  management 
system  and  generating  the  executable  files.  A  baseline  that  is 
delivered  to  a  customer  is  typically  called  a  “release”  whereas 
a  baseline  for  an  internal  use  is  typically  called  a  “build.  ” 

[PA159.IG101.SP103.N101.AMP1 02] 


Typical  Work  Products 

1.  Baselines  [pais9.igioi.spio3.wioi] 

2.  Description  of  baselines  [pai59.igioi.spio3.wio2] 


Subpractices 

1.  Obtain  authorization  from  the  configuration  control  board  (CCB) 
before  creating  or  releasing  baselines  of  configuration  items. 

[PA159.IG101.SP103.SubP101] 

2.  Create  or  release  baselines  only  from  configuration  items  in  the 
configuration  management  system.  [PAi59.iGioi.spio3.subPio2] 

3.  Document  the  set  of  configuration  items  that  are  contained  in  a 
baseline.  [PAi59.iGioi.spio3.subPio3] 

4.  Make  the  current  set  of  baselines  readily  available. 

[PA159.IG101  ,SP103.SubP104] 


SG  2  Track  and  Control  Changes 

Changes  to  the  work  products  under  configuration  management  are  tracked 
and  controlled.  ipai59.igio2] 

The  specific  practices  under  this  specific  goal  serve  to  maintain  the 
baselines  after  they  are  established  by  the  specific  practices  under  the 
Establish  Baselines  specific  goal.  [PAi59.iGio2.Nioi] 
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SP  2.1-1  Track  Change  Requests 

Track  change  requests  for  the  configuration  items,  [pai59.igw2.spwi] 


Change  requests  address  not  only  new  or  changed  requirements,  but 
also  failures  and  defects  in  the  work  products,  ipai59.igio2.spioi.nioi] 

Change  requests  are  analyzed  to  determine  the  impact  that  the  change 
will  have  on  the  work  product,  related  work  products,  and  schedule  and 

cost.  [PA159.IG102.SP101.N102] 

Typical  Work  Products 

1 .  Change  requests  [pai59.igio2.spioi.wioi] 

Subpractices 

1.  Initiate  and  record  change  requests  in  the  change  request 
database.  [PAi59.iGio2.spioi.subPioi] 

2.  Analyze  the  impact  of  changes  and  fixes  proposed  in  the  change 

requests.  [PA159.IG102.SP101.SubP102] 

Changes  are  evaluated  through  activities  that  ensure  that  they  are  consistent  with 
all  technical  and  project  requirements.  [PAi59.iGi02.sp101.subPi02.Ni0i] 

Changes  are  evaluated  for  their  impact  beyond  immediate  project  or  contract 
requirements.  Changes  to  an  item  used  in  multiple  products  can  resolve  an 
immediate  issue  while  causing  a  problem  in  other  applications. 

[PA159.IG102.SP101.SubP102.N102] 

3.  Review  change  requests  that  will  be  addressed  in  the  next  baseline 
with  those  who  will  be  affected  by  the  changes  and  get  their 
agreement.  [PAi59.iGio2.spioi.subPio3] 

Conduct  the  change  request  review  with  appropriate  participants.  Record  the 
disposition  of  each  change  request  and  the  rationale  for  the  decision,  including 
success  criteria,  a  brief  action  plan  if  appropriate,  and  needs  met  or  unmet  by  the 
change.  Perform  the  actions  required  in  the  disposition,  and  report  the  results  to 
relevant  stakeholders.  [PAi59.iGi02.sp101.subPi03.Ni0i] 

4.  Track  the  status  of  change  requests  to  closure.  [PAi59.iGio2.spioi.subPio4] 

Change  requests  brought  into  the  system  need  to  be  handled  in  a  proficient  and 
timely  manner.  Once  a  change  request  has  been  processed,  it  is  critical  to  close 
the  request  with  the  appropriate  approved  action  as  soon  as  it  is  practical.  Actions 
left  open  result  in  larger  than  necessary  status  lists,  which  in  turn  result  in  added 
costs  and  confusion.  [PAi59.iGi02.sp101.subPi04.Ni0i] 


SP  2.2-1  Control  Configuration  Items 

Control  changes  to  the  configuration  items.  [paiss.igio2.spio2] 
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Control  is  maintained  over  the  configuration  of  the  work  product 
baseline.  This  control  includes  tracking  the  configuration  of  each  of  the 
configuration  items,  approving  a  new  configuration  if  necessary,  and 
updating  the  baseline.  [PAi59.iGi02.sp102.Ni0i] 

Typical  Work  Products 

1 .  Revision  history  of  configuration  items  [PAi59.iGi02.sp102.w10i] 

2.  Archives  of  the  baselines  [PAi59.iGi02.sp102.w102] 

Subpractices 

1 .  Control  changes  to  configuration  items  throughout  the  life  of  the 

product.  [PA159.IG102.SP1 02. SubPI 01] 

2.  Obtain  appropriate  authorization  before  changed  configuration 
items  are  entered  into  the  configuration  management  system. 

[PA159.IG102.SP102.SubP102] 


For  example,  authorization  may  come  from  the  CCB,  the  project  manager,  or  the 
customer.  [PAi59.iGi02.sp102.subPi02.Ni0i] 


3.  Check  in  and  check  out  configuration  items  from  the  configuration 
management  system  for  incorporation  of  changes  in  a  manner  that 
maintains  the  correctness  and  integrity  of  the  configuration  items. 

[PA159.IG102.SP1 02. SubPI  03] 


Examples  of  check-in  and  check-out  steps  include  the  following: 

[PA159.IG102.SP102.SubP103.N101] 

•  Confirming  that  the  revisions  are  authorized 

•  Updating  the  configuration  items 

•  Archiving  the  replaced  baseline  and  retrieving  the  new  baseline 

4.  Perform  reviews  to  ensure  that  changes  have  not  caused 
unintended  effects  on  the  baselines  (e.g.,  ensure  that  the  changes 
have  not  compromised  the  safety  and/or  security  of  the  system). 

[PA159.IG102.SP102.SubP104] 

5.  Record  changes  to  configuration  items  and  the  reasons  for  the 
changes  as  appropriate.  [PAi59.iGio2.spio2.subPio5] 

If  a  proposed  change  to  the  work  product  is  accepted,  a  schedule  is  identified  for 
incorporating  the  change  into  the  work  product  and  other  affected  areas. 

[PA159.IG102.SP102.SubP105.N101] 


Configuration  control  mechanisms  can  be  tailored  to  categories  of  changes.  For 
example,  the  approval  considerations  could  be  less  stringent  for  component 
changes  that  do  not  affect  other  components.  [PAi59.iGi02.sp102.subPi05.Ni02] 
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Changed  configuration  items  are  released  after  review  and  approval  of 
configuration  changes.  Changes  are  not  official  until  they  are  released. 

[PA159.IG102.SP102.SubP105.N103] 


SG  3  Establish  Integrity 


Integrity  of  baselines  is  established  and  maintained.  pais9.igio3] 

The  integrity  of  the  baselines,  established  by  processes  associated  with 
the  Establish  Baselines  specific  goal,  and  maintained  by  processes 
associated  with  the  Track  and  Control  Changes  specific  goal,  is 
provided  by  the  specific  practices  under  this  specific  goal,  [pai59.igio3.nioi] 


SP  3.1-1  Establish  Configuration  Management  Records 

Establish  and  maintain  records  describing  configuration  items. 

[PA159.IG103.SP101] 


Typical  Work  Products 

1 .  Revision  history  of  configuration  items  [pai59.igio3.spioi.wioi] 

2.  Change  log  [PAi59.iGi03.sp101.w102] 

3.  Copy  of  the  change  requests  [pais9.igio3.spioi.wio3] 

4.  Status  of  configuration  items  [pai59.igio3.spioi.wio4] 

5.  Differences  between  baselines  [pai59.igio3.spioi.wio5] 

Subpractices 

1 .  Record  configuration  management  actions  in  sufficient  detail  so  the 
content  and  status  of  each  configuration  item  is  known  and 
previous  versions  can  be  recovered.  [PAi59.iGio3.spioi.subPioi] 

2.  Ensure  that  relevant  stakeholders  have  access  to  and  knowledge 
of  the  configuration  status  of  the  configuration  items. 

[PA159.IG103.SP101.SubP102] 

Examples  of  activities  for  communicating  configuration  status  include  the 
following:  [PAi59.iGio3.sp101.subPio2.Nioi] 

•  Providing  access  permissions  to  authorized  end  users 

•  Making  baseline  copies  readily  available  to  authorized  end  users 

3.  Specify  the  latest  version  of  the  baselines.  [PAi59.iGio3.spioi.subPio3] 

4.  Identify  the  version  of  configuration  items  that  constitute  a 
particular  baseline.  [PAi59.iGio3.spioi.subPio4] 
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5.  Describe  the  differences  between  successive  baselines. 

[PA159.IG103.SP101.SubP105] 

6.  Revise  the  status  and  history  (i.e.,  changes  and  other  actions)  of 
each  configuration  item  as  necessary.  [PAi59.iGio3.spioi.subPio6] 


SP  3.2-1  Perform  Configuration  Audits 

Perform  configuration  audits  to  maintain  integrity  of  the 
configuration  baselines.  [pais9.igio3.spio2] 


Audit  configuration  management  activities  and  processes  to  confirm 
that  the  resulting  baselines  and  documentation  are  accurate,  and  record 
the  audit  results  as  appropriate,  [pai59.igio3.spio2.nioi] 

Typical  Work  Products 

1.  Configuration  audit  results  [PAi59.iGi03.sp102.w10i] 

2.  Action  items  [PA159.IG103.SP102.W102] 

Subpractices 

1 .  Assess  the  integrity  of  the  baselines.  [PAi59.iGio3.spio2.subPioi] 

2.  Confirm  that  the  configuration  records  correctly  identify  the 
configuration  of  the  configuration  items.  [PAi59.iGio3.spio2.subPio2] 

3.  Review  the  structure  and  integrity  of  the  items  in  the  configuration 
management  system.  [PAi59.iGio3.spio2.subPio3] 

4.  Confirm  the  completeness  and  correctness  of  the  items  in  the 
configuration  management  system.  [PAi59.iGio3.spio2.subPio4] 

Completeness  and  correctness  of  the  content  is  based  on  the  requirements  as 
stated  in  the  plan  and  the  disposition  of  approved  change  requests. 

[PA159.IG103.SP102.SubP104.N101] 

5.  Confirm  compliance  with  applicable  configuration  management 
standards  and  procedures.  [PAi59.iGio3.spio2.subPio5] 

6.  Track  action  items  from  the  audit  to  closure.  [PAi59.iGio3.spio2.subPioe] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


458 


Support,  Configuration  Management 


CMMI-SW,  vl.1 
Continuous  Representation 

GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  configuration  management 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [GP102] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  configuration  management  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  establishing  and 
maintaining  baselines,  tracking  and  controlling  changes  to  the  work 
products  (under  configuration  management),  and  establishing  and 
maintaining  integrity  of  the  baselines,  ipaiss.elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  configuration 
management  process.  [gpio4] 


Elaboration: 

This  plan  for  performing  the  configuration  management  process  can  be 
included  in  (or  referenced  by)  the  project  plan,  which  is  described  in  the 
Project  Planning  process  area.  [pais9.elii2] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  configuration 
management  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpios] 
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Elaboration: 

Examples  of  resources  provided  include  the  following  tools:  [pais9.elio4] 

•  Configuration  management  tools 

•  Data  management  tools 

•  Archiving  and  reproduction  tools 

•  Database  programs 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
configuration  management  process,  igpiob] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  configuration 
management  process  as  needed.  [GP1071 

Elaboration: 

Examples  of  training  topics  include  the  following:  [PAmEuos] 

•  Roles,  responsibilities,  and  authority  of  the  configuration  management  staff 

•  Configuration  management  standards,  procedures,  and  methods 

•  Configuration  library  system 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  configuration  management 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 
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Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais9.elio6] 

•  Access  lists 

•  Change  status  reports 

•  Change  request  database 

•  CCB  meeting  minutes 

•  Archived  baselines 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  configuration 
management  process  as  planned.  [gpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [paisb.elih] 

•  Establishing  baselines 

•  Reviewing  configuration  management  system  reports  and  resolving  issues 

•  Assessing  the  impact  of  changes  for  the  configuration  items 

•  Performing  configuration  audits 

•  Reviewing  the  results  of  configuration  management  audits 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  configuration  management  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuoj 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA159.EL108] 

•  Number  of  changes  to  configuration  items 

•  Number  of  configuration  audits  conducted 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  configuration  management 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [gpusj 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai59.elio9] 

•  Establishing  baselines 

•  Tracking  and  controlling  changes 

•  Establishing  and  maintaining  integrity  of  baselines 

Examples  of  work  products  reviewed  include  the  following:  [pai59.elho] 

•  Archives  of  the  baselines 

•  Change  request  database 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  configuration 
management  process  with  higher  level  management  and  resolve 
issues,  [gpii  2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  configuration 
management  process,  [gpiuj 

GP  3.2 

Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  configuration  management  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

GG  4 

Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the 
configuration  management  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gphsj 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  configuration  management  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  [gpiwj 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  configuration  management 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP125] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  configuration  management  process.  [GP121] 
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PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 

Support 


Purpose 


The  purpose  of  Process  and  Product  Quality  Assurance  is  to  provide 
staff  and  management  with  objective  insight  into  processes  and 
associated  work  products,  [pahs] 


Introductory  Notes 


The  Process  and  Product  Quality  Assurance  process  area  involves  the 
following:  [pams.nioi] 

•  Objectively  evaluating  performed  processes,  work  products,  and 
services  against  the  applicable  process  descriptions,  standards, 
and  procedures 

•  Identifying  and  documenting  noncompliance  issues 

•  Providing  feedback  to  project  staff  and  managers  on  the  results  of 
quality  assurance  activities 

•  Ensuring  that  noncompliance  issues  are  addressed 

The  Process  and  Product  Quality  Assurance  process  area  supports  the 
delivery  of  high-quality  products  and  services  by  providing  the  project 
staff  and  managers  at  all  levels  with  appropriate  visibility  into,  and 
feedback  on,  processes  and  associated  work  products  throughout  the 
life  of  the  project.  [PA145.N102] 

The  practices  in  the  Process  and  Product  Quality  Assurance  process 
area  ensure  that  planned  processes  are  implemented,  while  the 
practices  in  the  Verification  process  area  ensure  that  the  specified 
requirements  are  satisfied.  These  two  process  areas  may  on  occasion 
address  the  same  work  product  but  from  different  perspectives.  Projects 
should  take  care  to  minimize  duplication  of  effort,  [pa-ms.nicb] 
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Objectivity  in  process  and  product  quality  assurance  evaluations  is 
critical  to  the  success  of  the  project.  (See  the  definition  of  “objectively 
evaluate”  in  Appendix  C,  the  glossary.)  Objectivity  is  achieved  by  both 
independence  and  the  use  of  criteria.  Traditionally,  a  quality  assurance 
group  that  is  independent  of  the  project  provides  this  objectivity.  It  may 
be  appropriate  in  some  organizations,  however,  to  implement  the 
process  and  product  quality  assurance  role  without  that  kind  of 
independence.  For  example,  in  an  organization  with  an  open,  quality- 
oriented  culture,  the  process  and  product  quality  assurance  role  may  be 
performed,  partially  or  completely,  by  peers;  and  the  quality  assurance 
function  may  be  embedded  in  the  process,  [pams  nkm] 

If  quality  assurance  is  embedded  in  the  process,  several  issues  must  be 
addressed  to  ensure  objectivity.  Everyone  performing  quality  assurance 
activities  should  be  trained  in  quality  assurance.  Those  performing 
quality  assurance  activities  for  a  work  product  should  be  separate  from 
those  directly  involved  in  developing  or  maintaining  the  work  product. 

An  independent  reporting  channel  to  the  appropriate  level  of 
organizational  management  must  be  available  so  that  noncompliance 
issues  may  be  escalated  as  necessary,  [pams.nios] 

Quality  assurance  should  begin  in  the  early  phases  of  a  project  to 
establish  plans,  processes,  standards,  and  procedures  that  will  add 
value  to  the  project  and  satisfy  the  requirements  of  the  project  and  the 
organizational  policies.  Those  performing  quality  assurance  participate 
in  establishing  the  plans,  processes,  standards,  and  procedures  to 
ensure  that  they  fit  the  project’s  needs  and  that  they  will  be  useable  for 
performing  quality  assurance  evaluations.  In  addition,  the  specific 
processes  and  associated  work  products  that  will  be  evaluated  during 
the  project  are  designated.  This  designation  may  be  based  on  sampling 
or  on  objective  criteria  that  are  consistent  with  organizational  policies 
and  project  requirements  and  needs,  [pams.nkw] 

When  noncompliance  issues  are  identified,  they  are  first  addressed 
within  the  project  and  resolved  there  if  possible.  Any  noncompliance 
issues  that  cannot  be  resolved  within  the  project  are  escalated  to  an 
appropriate  level  of  management  for  resolution,  [pams.nw] 

This  process  area  primarily  applies  to  evaluations  of  products  and 
services,  but  it  also  applies  to  evaluations  of  nonproject  activities  and 
work  products  such  as  training  activities.  For  these  activities  and  work 
products,  the  term  “project”  should  be  appropriately  interpreted. 

[PA145.N108] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
identifying  processes  and  associated  work  products  that  will  be 
objectively  evaluated,  [paus.rioi] 
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Refer  to  the  Verification  process  area  for  more  information  about 
satisfying  specified  requirements.  [paus.rio2] 


Specific  Goals 


SG  1  Objectively  Evaluate  Processes  and  Work  Products  [pams.igioi] 


Adherence  of  the  performed  process  and  associated  work  products  and 
services  to  applicable  process  descriptions,  standards,  and  procedures  is 
objectively  evaluated. 


SG  2  Provide  Objective  Insight  [pai45.igio2] 


Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Objectively  Evaluate  Processes  and  Work  Products  [paus.igioii 
SP  1.1-1  Objectively  Evaluate  Processes 
SP  1.2-1  Objectively  Evaluate  Work  Products  and  Services 
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SG  2  Provide  Objective  Insight  [pahs.igio2] 

SP  2.1-1  Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 
SP  2.2-1  Establish  Records 


GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize  a 

Managed  Process  [clio3.ghoi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a 

Defined  Process  [clkhglioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize  a 

Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliobglioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Objectively  Evaluate  Processes  and  Work  Products 


Adherence  of  the  performed  process  and  associated  work  products  and 
services  to  applicable  process  descriptions,  standards,  and  procedures  is 
objectively  evaluated,  [paus.igioi] 


SP  1.1-1  Objectively  Evaluate  Processes 

Objectively  evaluate  the  designated  performed  processes  against 
the  applicable  process  descriptions,  standards,  and  procedures. 

[PA145.IG101.SP101] 


Objectivity  in  quality  assurance  evaluations  is  critical  to  the  success  of 
the  project.  A  description  of  the  quality  assurance  reporting  chain  and 
how  it  ensures  objectivity  should  be  defined,  [pahs.igioi.spioi.nioi] 

Typical  Work  Products 

1.  Evaluation  reports  [pahs.igioi.spioi.wioi] 
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2.  Noncompliance  reports  [pah5.igioi.spioi.wio2] 

3.  Corrective  actions  [pai45.igioi.spioi.wio3] 

Subpractices 

1 .  Promote  an  environment  (created  as  part  of  project  management) 
that  encourages  employee  participation  in  identifying  and  reporting 
quality  issues.  [PAus.iGioi.spioi.subPioi] 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluations. 

[PA145.IG101.SP101.SubP102] 

The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such 
as  the  following:  [PAi45.iGio1.sp101.subPio2.Nioi] 

•  What  will  be  evaluated 

•  When  or  how  often  a  process  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  to  evaluate  performed  processes  for 
adherence  to  process  descriptions,  standards,  and  procedures. 

[PA145.IG101.SP101.SubP103] 

4.  Identify  each  noncompliance  found  during  the  evaluation. 

[PA145.IG101.SP101.SubP104] 

5.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services.  [PAHs.iGioi.spioi.subPiosi 


SP  1.2-1  Objectively  Evaluate  Work  Products  and  Services 

Objectively  evaluate  the  designated  work  products  and  services 
against  the  applicable  process  descriptions,  standards,  and 
procedures.  [pau5.igioi.spio2] 

Typical  Work  Products 

1.  Evaluation  reports  [pah5.igioi.spio2.wioi] 

2.  Noncompliance  reports  [pah5.igioi.spio2.wio2] 

3.  Corrective  actions  [pah5.igioi.spio2.wio3] 

Subpractices 

1 .  Select  work  products  to  be  evaluated,  based  on  documented 
sampling  criteria  if  sampling  is  used.  [PAH5.iGioi.spio2.subPioi] 

2.  Establish  and  maintain  clearly  stated  criteria  for  the  evaluation  of 
work  products.  [PAi45.iGioi.spio2.subPio2] 
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The  intent  of  this  subpractice  is  to  provide  criteria,  based  on  business  needs,  such 
as  the  following:  [PAi45.iGio1.sp102.subPio2.Nioi] 

•  What  will  be  evaluated  during  the  evaluation  of  a  work  product 

•  When  or  how  often  a  work  product  will  be  evaluated 

•  How  the  evaluation  will  be  conducted 

•  Who  must  be  involved  in  the  evaluation 

3.  Use  the  stated  criteria  during  the  evaluations  of  work  products. 

[PA145.IG101.SP102.SubP103] 

4.  Evaluate  work  products  before  they  are  delivered  to  the  customer. 

[PA145.IG101.SP102.SubP104] 

5.  Evaluate  work  products  at  selected  milestones  in  their 
development.  [PAi45.iGioi.spio2.subPios] 

6.  Perform  in-progress  or  incremental  evaluations  of  work  products 
and  services  against  process  descriptions,  standards,  and 
procedures.  [PAi45.iGioi.spio2.subPio6] 

7.  Identify  each  case  of  noncompliance  found  during  the  evaluations. 

[PA145.IG101.SP102.SubP107] 

8.  Identify  lessons  learned  that  could  improve  processes  for  future 
products  and  services.  [PAi45.iGioi.spio2.subPios] 

SG  2  Provide  Objective  Insight 

Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured.  [paus.igio2] 


SP  2.1-1  Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 

Communicate  quality  issues  and  ensure  resolution  of 
noncompliance  issues  with  the  staff  and  managers.  [paus.igio2.spioi] 


Noncompliance  issues  are  problems  identified  in  evaluations  that  reflect 
a  lack  of  adherence  to  applicable  standards,  process  descriptions,  or 
procedures.  The  status  of  noncompliance  issues  provides  an  indication 
of  quality  trends.  Quality  issues  include  noncompliance  issues  and 
results  of  trend  analysis,  [pai45.igio2.spioi.nioi] 

When  local  resolution  of  noncompliance  issues  cannot  be  obtained,  use 
established  escalation  mechanisms  to  ensure  that  the  appropriate  level 
of  management  can  resolve  the  issue.  Track  noncompliance  issues  to 

resolution.  [PAH5.IG102.SP101.N102] 
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Typical  Work  Products 

1.  Corrective  action  reports  [pai45.igio2.spioi.wioi] 

2.  Evaluation  reports  [PAi45.iGi02.sp101.w102] 

3.  Quality  trends  [PAi45.iGi02.sp101.w103] 

Subpractices 

1 .  Resolve  each  noncompliance  with  the  appropriate  members  of  the 
staff  where  possible.  [PAi45.iGio2.spioi.subPioi] 

2.  Document  noncompliance  issues  when  they  cannot  be  resolved 
within  the  project.  [PAi45.iGio2.spioi.subPio2] 

Examples  of  ways  to  resolve  noncompliance  within  the  project  include  the 
following:  [PAi45.iGio2.sp101.subPio2.Nioi] 

•  Fixing  the  noncompliance 

•  Changing  the  process  descriptions,  standards,  or  procedures  that  were  violated 

•  Obtaining  a  waiver  to  cover  the  noncompliance  issue 


3.  Escalate  noncompliance  issues  that  cannot  be  resolved  within  the 
project  to  the  appropriate  level  of  management  designated  to 
receive  and  act  on  noncompliance  issues.  [PAi45.iGio2.spioi.subPio3] 

4.  Analyze  the  noncompliance  issues  to  see  if  there  are  any  quality 
trends  that  can  be  identified  and  addressed.  [PAH5.iGio2.spioi.subPio4] 

5.  Ensure  that  relevant  stakeholders  are  aware  of  the  results  of 
evaluations  and  the  quality  trends  in  a  timely  manner. 

[PA145.IG102.SP101.SubP105] 

6.  Periodically  review  open  noncompliance  issues  and  trends  with  the 
manager  designated  to  receive  and  act  on  noncompliance  issues. 

[PA145.IG102.SP101.SubP106] 

7.  Track  noncompliance  issues  to  resolution.  [PAi45.iGio2.spioi.subPio7] 


SP  2.2-1  Establish  Records 

Establish  and  maintain  records  of  the  quality  assurance  activities. 

[PA  145.IG102.SP102] 

Typical  Work  Products 

1 .  Evaluation  logs  [PAi45.iGi02.sp102.w10i] 

2.  Quality  assurance  reports  [pah5.igio2.spio2.wio2] 

3.  Status  reports  of  corrective  actions  [pah5.igio2.spio2.wio3] 

4.  Reports  of  quality  trends  [pah5.igio2.spio2.wio4] 
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Subpractices 

1 .  Record  process  and  product  quality  assurance  activities  in 
sufficient  detail  such  that  status  and  results  are  known. 

[PA145.IG102.SP102.SubP101] 

2.  Revise  the  status  and  history  of  the  quality  assurance  activities  as 
necessary.  [PAi45.iGio2.spio2.subPio2] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  process  and  product  quality 
assurance  process  to  develop  work  products  and  provide  services 
to  achieve  the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process  and  product  quality  assurance  process. 

[GP103] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  objectively 
evaluating  whether  processes  and  associated  work  products  adhere  to 
the  applicable  process  descriptions,  standards,  and  procedures,  and 
ensuring  that  noncompliance  is  addressed,  [pams.elioij 

This  policy  also  establishes  organizational  expectations  for  process  and 
product  quality  assurance  being  in  place  for  all  projects.  Process  and 
product  quality  assurance  must  possess  sufficient  independence  from 
project  management  to  provide  objectivity  in  identifying  and  reporting 
noncompliance  issues,  [pams.elkk] 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process  and 
product  quality  assurance  process.  [gpio4] 


Elaboration: 

This  plan  for  performing  the  process  and  product  quality  assurance 
process  may  be  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area,  [pams.elim] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process  and 
product  quality  assurance  process,  developing  the  work  products, 
and  providing  the  services  of  the  process,  [gpios] 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools:  [pams.elios] 

•  Evaluation  tools 

•  Noncompliance  tracking  tool 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process  and  product  quality  assurance  process,  [gpiosj 


Elaboration: 

To  guard  against  subjectivity  or  bias,  ensure  that  those  people  assigned 
responsibility  and  authority  for  process  and  product  quality  assurance 
can  perform  their  evaluations  with  sufficient  independence  and 
objectivity,  [pa-ms.elhs] 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  and 
product  quality  assurance  process  as  needed.  igpio7] 
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Elaboration: 

Examples  of  training  topics  include  the  following:  [pai45  eliosj 

•  Application  domain 

•  Customer  relations 

•  Process  descriptions,  standards,  procedures,  and  methods  for  the  project 

•  Quality  assurance  objectives,  process  descriptions,  standards,  procedures, 

methods,  and  tools 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  and  product 
quality  assurance  process  under  appropriate  levels  of 
configuration  management,  [gpiosj 


Elaboration: 


Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pams.elih] 

•  Noncompliance  reports 

•  Evaluation  logs  and  reports 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  process  and 
product  quality  assurance  process  as  planned.  igpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai45.elh3] 

•  Establishing  criteria  for  the  objective  evaluations  of  processes  and  work  products 

•  Evaluating  processes  and  work  products 

•  Resolving  noncompliance  issues 

•  Tracking  noncompliance  issues  to  closure 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  and  product  quality  assurance 
process  against  the  plan  for  performing  the  process  and  take 
appropriate  corrective  action,  [g phoj 
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Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA145.EL108] 

•  Variance  of  objective  process  evaluations  planned  and  performed 

•  Variance  of  objective  work  product  evaluations  planned  and  performed 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  and  product  quality 
assurance  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance.  [GP1131 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai45.elio9] 

•  Objectively  evaluating  processes  and  work  products 

•  Tracking  and  communicating  noncompliance  issues 

Examples  of  work  products  reviewed  include  the  following:  [pai45.elh2] 

•  Noncompliance  reports 

•  Evaluation  logs  and  reports 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  and 
product  quality  assurance  process  with  higher  level  management 
and  resolve  issues,  ig pmi 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process  and 
product  quality  assurance  process,  igpiuj 
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GP  3.2 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  process  and  product  quality  assurance  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes  and 
process  assets,  [g pmj 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the  process  and 
product  quality  assurance  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gpusj 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  and  product  quality  assurance 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  [gpiwi 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Ensure  continuous  improvement  of  the  process  and  product 
quality  assurance  process  in  fulfilling  the  relevant  business 
objectives  of  the  organization.  [GP1251 

Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  process  and  product  quality  assurance  process.  [GP1211 
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MEASUREMENT  AND  ANALYSIS 

Support 


Purpose 


The  purpose  of  Measurement  and  Analysis  is  to  develop  and  sustain  a 
measurement  capability  that  is  used  to  support  management 
information  needs.  [pai54] 


Introductory  Notes 


The  Measurement  and  Analysis  process  area  involves  the  following: 

[PA154.N101] 

•  Specifying  the  objectives  of  measurement  and  analysis  such  that 
they  are  aligned  with  identified  information  needs  and  objectives 

•  Specifying  the  measures,  data  collection  and  storage  mechanisms, 
analysis  techniques,  and  reporting  and  feedback  mechanisms 

•  Implementing  the  collection,  storage,  analysis,  and  reporting  of  the 
data 

•  Providing  objective  results  that  can  be  used  in  making  informed 
decisions,  and  taking  appropriate  corrective  actions 

The  integration  of  measurement  and  analysis  activities  into  the 
processes  of  the  project  supports  the  following:  [pai54.nio2] 

•  Objective  planning  and  estimating 

•  Tracking  actual  performance  against  established  plans  and 
objectives 

•  Identifying  and  resolving  process-related  issues 

•  Providing  a  basis  for  incorporating  measurement  into  additional 
processes  in  the  future 

The  staff  required  to  implement  a  measurement  capability  may  or  may 
not  be  employed  in  a  separate  organization-wide  program. 
Measurement  capability  may  be  integrated  into  individual  projects  or 
other  organizational  functions  (e.g.,  Quality  Assurance).  [pais4nio3] 

The  initial  focus  for  measurement  activities  is  at  the  project  level. 
However,  a  measurement  capability  may  prove  useful  for  addressing 
organization-  and/or  enterprise-wide  information  needs.  [pais4  nio4] 
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Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 
repository.  [pai54.nios] 


Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

[PA154.R101] 


Refer  to  the  Project  Monitoring  &  Control  process  area  for  more 
information  about  monitoring  project  performance  information  needs. 

[PA154.R102] 


Refer  to  the  Configuration  Management  process  area  for  more 
information  about  managing  measurement  work  products.  [pais4.rio3] 

Refer  to  the  Requirements  Development  process  area  for  more 
information  about  meeting  customer  requirements  and  related 
information  needs.  [pais4.rio4] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs.  [pais4.rios] 

Refer  to  the  Organizational  Process  Definition  process  area  for  more 
information  about  establishing  the  organization’s  measurement 
repository.  [pais4.rio6] 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  understanding  variation  and  the  appropriate  use  of 
statistical  analysis  techniques.  [PA154.R107] 


Specific  Goals 


SG  1  Align  Measurement  and  Analysis  Activities  [pais4.igioi] 


Measurement  objectives  and  activities  are  aligned  with  identified  information 
needs  and  objectives. 


SG  2  Provide  Measurement  Results  [pai54.igio2] 


Measurement  results  that  address  identified  information  needs  and  objectives 
are  provided. 
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Generic  Goals 


GG  1 

Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG2 

Institutionalize  a  Managed  Process  [clkb.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3 

Institutionalize  a  Defined  Process  [clkm.glioii 

The  process  is  institutionalized  as  a  defined  process. 

GG  4 

Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5 

Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Align  Measurement  and  Analysis  Activities  [paim.igioi] 

SP  1.1-1  Establish  Measurement  Objectives 

SP  1.2-1  Specify  Measures 

SP  1.3-1  Specify  Data  Collection  and  Storage  Procedures 

SP  1.4-1  Specify  Analysis  Procedures 

SG  2  Provide  Measurement  Results  [pai54.igio2] 

SP  2.1-1  Collect  Measurement  Data 

SP  2.2-1  Analyze  Measurement  Data 

SP  2.3-1  Store  Data  and  Results 

SP  2.4-1  Communicate  Results 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [cho3ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 
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GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clim.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [clio6.glioii 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 


Specific  Practices  by  Goal 


SG  1  Align  Measurement  and  Analysis  Activities 


Measurement  objectives  and  activities  are  aligned  with  identified  information 
needs  and  objectives.  ipais4.igioi] 

The  specific  practices  covered  under  this  specific  goal  may  be 

addressed  concurrently  or  in  any  order:  [pai54.igioi.nioi] 

•  When  establishing  measurement  objectives,  experts  often  think 
ahead  about  necessary  criteria  for  specifying  measures  and 
analysis  procedures.  They  also  think  concurrently  about  the 
constraints  imposed  by  data  collection  and  storage  procedures. 

•  It  often  is  important  to  specify  the  essential  analyses  that  will  be 
conducted  before  attending  to  details  of  measurement 
specification,  data  collection,  or  storage. 


SP  1.1-1  Establish  Measurement  Objectives 

Establish  and  maintain  measurement  objectives  that  are  derived 
from  identified  information  needs  and  objectives.  [pais4.igioi.spioi] 


Measurement  objectives  document  the  purposes  for  which 
measurement  and  analysis  are  done,  and  specify  the  kinds  of  actions 
that  may  be  taken  based  on  the  results  of  data  analyses. 

[PA154.IG101.SP101.N101] 


The  sources  for  measurement  objectives  may  be  management, 
technical,  project,  product,  or  process  implementation  needs. 

[PA154.IG101.SP101.N102] 
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The  measurement  objectives  may  be  constrained  by  existing 
processes,  available  resources,  or  other  measurement  considerations. 
Judgments  may  need  to  be  made  about  whether  the  value  of  the  results 
will  be  commensurate  with  the  resources  devoted  to  doing  the  work. 

[PA154.IG101.SP101.N103] 

Modifications  to  identified  information  needs  and  objectives  may,  in 
turn,  be  indicated  as  a  consequence  of  the  process  and  results  of 
measurement  and  analysis,  [pai54.igioi.spioi.nio4] 

Sources  of  information  needs  and  objectives  may  include  the  following: 

[PA154.IG101.SP101.N105] 

•  Project  plans 

•  Monitoring  of  project  performance 

•  Interviews  with  managers  and  others  who  have  information  needs 

•  Established  management  objectives 

•  Strategic  plans 

•  Business  plans 

•  Formal  requirements  or  contractual  obligations 

•  Recurring  or  other  troublesome  management  or  technical  problems 

•  Experiences  of  other  projects  or  organizational  entities 

•  External  industry  benchmarks 

•  Process-improvement  plans 

Refer  to  the  Project  Planning  process  area  for  more  information  about 
estimating  project  attributes  and  other  planning  information  needs. 

[PA1S4.IG101.SP101.N105.R101] 


Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  about  project  performance  information  needs. 

[PA1S4.IG101.SP101.N105.R102] 


Refer  to  the  Requirements  Development  process  area  for  more 
information  about  meeting  customer  requirements  and  related 
information  needs,  [pais4.igioi.spioi.nios.rio3] 

Refer  to  the  Requirements  Management  process  area  for  more 
information  about  maintaining  requirements  traceability  and  related 
information  needs,  [pais4.igioi.spioi.nios.rio4] 

Typical  Work  Products 

1 .  Measurement  objectives  [pais4  igioi.spioi.wioi] 
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Subpractices 

1.  Document  information  needs  and  objectives.  [PAi54.iGioi.spioi.subPioi] 

Information  needs  and  objectives  are  documented  to  allow  traceability  to 
subsequent  measurement  and  analysis  activities.  [PAi54.iGioi.spioi.subPioi.Nioi] 

2.  Prioritize  information  needs  and  objectives.  [PAi54.iGioi.spioi.subPio2] 

It  may  be  neither  possible  nor  desirable  to  subject  all  initially  identified  information 
needs  to  measurement  and  analysis.  Priorities  may  also  need  to  be  set  within  the 
limits  of  available  resources.  [PAi54.iGi01.sp101.subPi02.Ni0i] 

3.  Document,  review,  and  update  measurement  objectives. 

[PA154.IG101.SP101.SubP103] 

It  is  important  to  carefully  consider  the  purposes  and  intended  uses  of 
measurement  and  analysis.  [PAi54.iGi01.sp101.subPi03.Ni0i] 

The  measurement  objectives  are  documented,  reviewed  by  management  and 
other  relevant  stakeholders,  and  updated  as  necessary.  Doing  so  enables 
traceability  to  subsequent  measurement  and  analysis  activities,  and  helps  ensure 
that  the  analyses  will  properly  address  identified  information  needs  and 
objectives.  [PAi54.iGio1.sp101.subPio3.Nio2] 

It  is  important  that  users  of  measurement  and  analysis  results  be  involved  in 
setting  measurement  objectives  and  deciding  on  plans  of  action.  It  may  also  be 
appropriate  to  involve  those  who  provide  the  measurement  data. 

[PA154.IG101.SP101.SubP103.N103] 

4.  Provide  feedback  for  refining  and  clarifying  information  needs  and 
objectives  as  necessary.  [PAi54.iGioi.spioi.subPio4] 

Identified  information  needs  and  objectives  may  need  to  be  refined  and  clarified 
as  a  result  of  setting  measurement  objectives.  Initial  descriptions  of  information 
needs  may  be  unclear  or  ambiguous.  Conflicts  may  arise  between  existing  needs 
and  objectives.  Precise  targets  on  an  already  existing  measure  may  be 
unrealistic.  [PAi54.iGio1.sp101.subPio4.Nioi] 

5.  Maintain  traceability  of  the  measurement  objectives  to  the  identified 
information  needs  and  objectives.  [PAi54.iGioi.spioi.subPio5] 

There  must  always  be  a  good  answer  to  the  question,  “Why  are  we  measuring 

thiS?”  [PA154.IG101.SP101.SubP105.N101] 

Of  course,  the  measurement  objectives  may  also  change  to  reflect  evolving 
information  needs  and  objectives.  [PAi54.iGi01.sp101.subPi05.Ni02] 
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SP  1.2-1  Specify  Measures 

Specify  measures  to  address  the  measurement  objectives. 

[PA  1 54.  IG  101.SP1 02] 

Measurement  objectives  are  refined  into  precise,  quantifiable 

measures,  [pai54.igioi.spio2.nioi] 

Measures  may  be  either  “base”  or  “derived.”  Data  for  base  measures 
are  obtained  by  direct  measurement.  Data  for  derived  measures  come 
from  other  data,  typically  by  combining  two  or  more  base  measures. 

[PA154.IG101.SP102.N102] 

Examples  of  commonly  used  base  measures  include  the  following:  [pai54.igioi.spio2.nio3] 

•  Estimates  and  actual  measures  of  work  product  size  (e.g.,  number  of  pages) 

•  Estimates  and  actual  measures  of  effort  and  cost  (e.g.,  number  of  person  hours) 

•  Quality  measures  (e.g.,  number  of  defects,  number  of  defects  by  severity) 

Examples  of  commonly  used  derived  measures  include  the  following:  [pai54.igioi.spio2.nio4] 

•  Earned  Value 

•  Schedule  Performance  Index 

•  Defect  density 

•  Peer  review  coverage 

•  Test  or  verification  coverage 

•  Reliability  measures  (e.g.,  mean  time  to  failure) 

•  Quality  measures  (e.g.,  number  of  defects  by  severity/total  number  of  defects) 


Derived  measures  typically  are  expressed  as  ratios,  composite  indices, 
or  other  aggregate  summary  measures.  They  are  often  more 
quantitatively  reliable  and  meaningfully  interpretable  than  the  base 
measures  used  to  generate  them,  [pai54.igioi.spio2.nio5] 

Typical  Work  Products 

1 .  Specifications  of  base  and  derived  measures  [pais4.igioi.spio2.wioi] 

Subpractices 

1.  Identify  candidate  measures  based  on  documented  measurement 

Objectives.  [PA154.IG101.SP102.SubP101] 

The  measurement  objectives  are  refined  into  specific  measures.  The  identified 
candidate  measures  are  categorized  and  specified  by  name  and  unit  of  measure. 

[PA154.IG101.SP102.SubP101.N101] 
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2.  Identify  existing  measures  that  already  address  the  measurement 

objectives.  [PA154.IG101.SP102.SubP102] 

Specifications  for  measures  may  already  exist,  perhaps  established  for  other 
purposes  earlier  or  elsewhere  in  the  organization.  [PAi54.iGim.sp102.subPi02.Ni0i] 

3.  Specify  operational  definitions  for  the  measures.  [PAi54.iGioi.spio2.subPio3] 

Operational  definitions  are  stated  in  precise  and  unambiguous  terms.  They 
address  two  important  criteria  as  follows:  [PAi54.iGi01.sp102.subPi03.Ni0i] 

•  Communication:  What  has  been  measured,  how  was  it  measured,  what  are  the 
units  of  measure,  and  what  has  been  included  or  excluded? 

•  Repeatability:  Can  the  measurement  be  repeated,  given  the  same  definition,  to 
get  the  same  results? 

4.  Prioritize,  review,  and  update  measures.  [PAi54.iGioi.spio2.subPio4] 

Proposed  specifications  of  the  measures  are  reviewed  for  their  appropriateness 
with  potential  end  users  and  other  relevant  stakeholders.  Priorities  are  set  or 
changed,  and  specifications  of  the  measures  are  updated  as  necessary. 

[PA154.IG101.SP102.SubP104.N101] 


SP  1.3-1  Specify  Data  Collection  and  Storage  Procedures 

Specify  how  measurement  data  will  be  obtained  and  stored. 

[PA154.IG101  .SP103] 


Explicit  specification  of  collection  methods  helps  ensure  that  the  right 
data  are  collected  properly.  It  may  also  aid  in  further  clarifying 
information  needs  and  measurement  objectives,  [pai54.igioi.spio3.nioi] 

Proper  attention  to  storage  and  retrieval  procedures  helps  ensure  that 
data  are  available  and  accessible  for  future  use.  [pai54.igioi.spio3.nio2] 

Typical  Work  Products 

1 .  Data  collection  and  storage  procedures  [pai54igioi.spio3.wioi] 

2.  Data  collection  tools  [PAi54.iGi01.sp103.w102] 

Subpractices 

1 .  Identify  existing  sources  of  data  that  are  generated  from  current 
work  products,  processes,  or  transactions.  [pais4.igioi  spio3.subPioi] 

Existing  sources  of  data  may  already  have  been  identified  when  specifying  the 
measures.  Appropriate  collection  mechanisms  may  exist  whether  or  not  pertinent 
data  have  already  been  collected.  [PAi54.iGi01.sp103.subPi01.Ni0i] 

2.  Identify  measures  for  which  data  are  needed,  but  are  not  currently 
available.  [PAi54.iGioi.spio3.subPio2] 
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3.  Specify  how  to  collect  and  store  the  data  for  each  required 
measure.  [PAi54.iGioi.spio3.subPio3] 

Explicit  specifications  are  made  of  how,  where,  and  when  the  data  will  be 
collected.  Procedures  for  collecting  valid  data  are  specified.  The  data  are  stored  in 
an  accessible  manner  for  analysis,  and  it  is  determined  whether  they  will  be  saved 
for  possible  reanalysis  or  documentation  purposes.  [PAi54.iGio1.sp103.subPio3.Nioi] 

Questions  to  be  considered  typically  include  the  following:  [PAi54.iGi01.sp103.subPi03.Ni02] 

•  Have  the  frequency  of  collection  and  the  points  in  the  process  where 
measurements  will  be  made  been  determined? 

•  Has  the  time  line  that  is  required  to  move  measurement  results  from  the  points  of 
collection  to  repositories,  other  databases,  or  end  users  been  established? 

•  Who  is  responsible  for  obtaining  the  data? 

•  Who  is  responsible  for  data  storage,  retrieval,  and  security? 

•  Have  necessary  supporting  tools  been  developed  or  acquired? 

4.  Create  data  collection  mechanisms  and  process  guidance. 

[PA1 54.IG1 01  .SP1 03.SubP1 04] 

Data  collection  and  storage  mechanisms  are  well  integrated  with  other  normal 
work  processes.  Data  collection  mechanisms  may  include  manual  or  automated 
forms  and  templates.  Clear,  concise  guidance  on  correct  procedures  is  available 
to  those  responsible  fordoing  the  work.  Training  is  provided  as  necessary  to 
clarify  the  processes  necessary  for  collection  of  complete  and  accurate  data  and 
to  minimize  the  burden  on  those  who  must  provide  and  record  the  data. 

[PA154.IG101.SP103.SubP104.N101] 

5.  Support  automatic  collection  of  the  data  where  appropriate  and 

feasible.  [PA154.IG101.SP103.SubP105] 

Automated  support  can  aid  in  collecting  more  complete  and  accurate  data. 

[PA154.IG101.SP103.SubP105.N101] 


Examples  of  such  automated  support  include  the  following:  [PAi54.iGio1.sp103.subPio5.Nio2] 

•  Timestamped  activity  logs 

•  Static  or  dynamic  analyses  of  artifacts 

However,  some  data  cannot  be  collected  without  human  intervention  (e.g., 
customer  satisfaction  or  other  human  judgments),  and  setting  up  the  necessary 
infrastructure  for  other  automation  may  be  costly.  [PAi54.iGi01.sp103.subPi05.Ni03] 

6.  Prioritize,  review,  and  update  data  collection  and  storage 
procedures.  [PAi54.iGioi.spio3.subPio6] 
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Proposed  procedures  are  reviewed  for  their  appropriateness  and  feasibility  with 
those  who  are  responsible  for  providing,  collecting,  and  storing  the  data.  They 
also  may  have  useful  insights  about  how  to  improve  existing  processes,  or  be 
able  to  suggest  other  useful  measures  or  analyses.  [PAi54.iGio1.sp103.subPio6.Nioi] 

7.  Update  measures  and  measurement  objectives  as  necessary. 

[PA1 54.IG1 01  .SP1 03.SubP1 07] 


Priorities  may  need  to  be  reset  based  on  the  following:  [PAi54.iGio1.sp103.subPio7.Nioi] 

•  The  importance  of  the  measures 

•  The  amount  of  effort  required  to  obtain  the  data 

Considerations  include  whether  new  forms,  tools,  or  training  would  be  required  to 
obtain  the  data.  [PAi54.iGio1.sp103.subPio7.Nio2] 


SP  1.4-1  Specify  Analysis  Procedures 

Specify  how  measurement  data  will  be  analyzed  and  reported. 

[PA1 54.IG101  .SP104] 


Specifying  the  analysis  procedures  in  advance  ensures  that  appropriate 
analyses  will  be  conducted  and  reported  to  address  the  documented 
measurement  objectives  (and  thereby  the  information  needs  and 
objectives  on  which  they  are  based).  This  approach  also  provides  a 
check  that  the  necessary  data  will  in  fact  be  collected,  [pai54.igioi.spio4.nioi] 

Typical  Work  Products 

1.  Analysis  specification  and  procedures  [pais4.igioi  spio4.wioi] 

2.  Data  analysis  tools  [pais4.igioi.spio4.wio2] 

Subpractices 

1 .  Specify  and  prioritize  the  analyses  that  will  be  conducted  and  the 
reports  that  will  be  prepared.  [PAis4.iGioi.spio4.subPioi] 

Early  attention  should  be  paid  to  the  analyses  that  will  be  conducted  and  to  the 
manner  in  which  the  results  will  be  reported.  These  should  meet  the  following 
criteria:  [PAi54.iGi01.sp104.subPi01.Ni0i] 

•  The  analyses  explicitly  address  the  documented  measurement  objectives 

•  Presentation  of  the  results  is  clearly  understandable  by  the  audiences  to  whom 
the  results  are  addressed 

Priorities  may  have  to  be  set  within  available  resources.  [PAi54.iGio1.sp104.subPio1.Nio2] 

2.  Select  appropriate  data  analysis  methods  and  tools. 

[PA1 54.IG1 01  .SP1 04.SubP1 02] 
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Refer  to  the  Select  Measures  and  Analytic  Techniques  and  Apply 
Statistical  Methods  to  Understand  Variation  specific  practices  of 
the  Quantitative  Project  Management  process  area  for  more 
information  about  the  appropriate  use  of  statistical  analysis 
techniques  and  understanding  variation,  respectively. 

[PA154.IG101.SP104.SubP102.R101] 

Issues  to  be  considered  typically  include  the  following:  [PAi54.iGi01.sp104.subPi02.Nioi] 

•  Choice  of  visual  display  and  other  presentation  techniques  (e.g.,  pie  charts,  bar 
charts,  histograms,  radar  charts,  line  graphs,  scatter  plots,  or  tables) 

•  Choice  of  appropriate  descriptive  statistics  (e.g.,  arithmetic  mean,  median,  or 
mode) 

•  Decisions  about  statistical  sampling  criteria  when  it  is  impossible  or  unnecessary 
to  examine  every  data  element 

•  Decisions  about  how  to  handle  analysis  in  the  presence  of  missing  data  elements 

•  Selection  of  appropriate  analysis  tools 

Descriptive  statistics  are  typically  used  in  data  analysis  to  do  the  following: 

[PA154.IG101.SP104.SubP102.N102] 

•  Examine  distributions  on  the  specified  measures  (e.g.,  central  tendency,  extent  of 
variation,  data  points  exhibiting  unusual  variation) 

•  Examine  the  interrelationships  among  the  specified  measures  (e.g.,  comparisons 
of  defects  by  phase  of  the  product’s  life  cycle  or  by  product  component) 

•  Display  changes  over  time 

3.  Specify  administrative  procedures  for  analyzing  the  data  and 
communicating  the  results.  [PAi54.iGioi.spio4.subPio3] 


Issues  to  be  considered  typically  include  the  following:  [PAi54.iGio1.sp104.subPio3.Nioi] 

•  Identifying  the  persons  and  groups  responsible  for  analyzing  the  data  and 
presenting  the  results 

•  Determining  the  time  line  to  analyze  the  data  and  present  the  results 

•  Determining  the  venues  for  communicating  the  results  (e.g.,  progress  reports, 
transmittal  memos,  written  reports,  or  staff  meetings) 

4.  Review  and  update  the  proposed  content  and  format  of  the 
specified  analyses  and  reports.  [PAi54.iGioi.spio4.subPio4] 

All  of  the  proposed  content  and  format  are  subject  to  review  and  revision, 
including  analytic  methods  and  tools,  administrative  procedures,  and  priorities. 
The  relevant  stakeholders  consulted  should  include  intended  end  users, 
sponsors,  data  analysts,  and  data  providers.  [PAi54.iGi01.sp104.subPi04.Ni0i] 

5.  Update  measures  and  measurement  objectives  as  necessary. 

[PA154.IG101.SP104.SubP105] 
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Just  as  measurement  needs  drive  data  analysis,  clarification  of  analysis  criteria 
can  affect  measurement.  Specifications  for  some  measures  may  be  refined  further 
based  on  the  specifications  established  for  data  analysis  procedures.  Other 
measures  may  prove  to  be  unnecessary,  or  a  need  for  additional  measures  may 
be  recognized.  [PAi54.iGio1.sp104.subPio5.Nioi] 

The  exercise  of  specifying  how  measures  will  be  analyzed  and  reported  may  also 
suggest  the  need  for  refining  the  measurement  objectives  themselves. 

[PA154.IG101.SP104.SubP105.N102] 

6.  Specify  criteria  for  evaluating  the  utility  of  the  analysis  results,  and 
of  the  conduct  of  the  measurement  and  analysis  activities. 

[PA154.IG101.SP104.SubP106] 


Criteria  for  evaluating  the  utility  of  the  analysis  might  address  the  extent  to  which 

the  following  apply:  [PAi54.iGi01.sp104.subPi06.Ni0i] 

•  The  results  are  (1)  provided  on  a  timely  basis,  (2)  understandable,  and  (3)  used 
for  decision  making. 

•  The  work  does  not  cost  more  to  perform  than  is  justified  by  the  benefits  that  it 
provides. 

Criteria  for  evaluating  the  conduct  of  the  measurement  and  analysis  might  include 

the  extent  to  which  the  following  apply:  [PAi54.iGi01.sp104.subPi06.Ni02] 

•  The  amount  of  missing  data  or  the  number  of  flagged  inconsistencies  is  beyond 
specified  thresholds. 

•  There  is  selection  bias  in  sampling  (e.g.,  only  satisfied  end  users  are  surveyed  to 
evaluate  end-user  satisfaction,  or  only  unsuccessful  projects  are  evaluated  to 
determine  overall  productivity). 

•  The  measurement  data  are  repeatable  (e.g.,  statistically  reliable). 

•  Statistical  assumptions  have  been  satisfied  (e.g.,  about  the  distribution  of  data  or 
about  appropriate  measurement  scales). 


SG  2  Provide  Measurement  Results 


Measurement  results  that  address  identified  information  needs  and  objectives 
are  provided.  [PA154.1G102] 

The  primary  reason  for  doing  measurement  and  analysis  is  to  address 
identified  information  needs  and  objectives.  Measurement  results  based 
on  objective  evidence  can  help  to  monitor  performance,  fulfill 
contractual  obligations,  make  informed  management  and  technical 
decisions,  and  enable  corrective  actions  to  be  taken,  [pais4.igio2.nioi] 


SP  2.1-1  Collect  Measurement  Data 

Obtain  specified  measurement  data,  [pai54.igio2.spwi] 
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The  data  necessary  for  analysis  are  obtained  and  checked  for 
completeness  and  integrity,  [pais4.igio2.spioi.nioi] 


Typical  Work  Products 

1 .  Base  and  derived  measurement  data  sets  [pais4.igio2.spioi.wioi] 

2.  Results  of  data  integrity  tests  [PAi54.iGi02.sp101.w102] 

Subpractices 

1 .  Obtain  the  data  for  base  measures.  [PAi54.iGio2.spioi.subPioi] 

Data  are  collected  as  necessary  for  previously  used  as  well  as  for  newly  specified 
base  measures.  Existing  data  are  gathered  from  project  records  or  from 
elsewhere  in  the  organization.  [PAi54.iGi02.sp101.subPi01.Ni0i] 

Note  that  data  that  were  collected  earlier  may  no  longer  be  available  for  reuse  in 
existing  databases,  paper  records,  or  formal  repositories.  [PAi54.iGio2.sp101.subPi01.Ni02] 

2.  Generate  the  data  for  derived  measures.  [PAi54.iGio2.spioi.subPio2] 

Values  are  newly  calculated  for  all  derived  measures.  [PAi54.iGio2.sp101.subPio2.Nioi] 

3.  Perform  data  integrity  checks  as  close  to  the  source  of  the  data  as 

pOSSible.  [PA154.IG102.SP101.SubP103] 

All  measurements  are  subject  to  error  in  specifying  or  recording  data.  It  is  always 
better  to  identify  such  errors  and  to  identify  sources  of  missing  data  early  in  the 
measurement  and  analysis  cycle.  [PAi54.iGi02.sp101.subPi03.Ni0i] 

Checks  can  include  scans  for  missing  data,  out-of-bounds  data  values,  and 
unusual  patterns  and  correlation  across  measures.  [PAi54.iGio2.sp101.subPi03.Ni02] 

It  is  particularly  important  to  do  the  following:  [PAi54.iGio2.sp101.subPio3.Nio3] 

•  Test  and  correct  for  inconsistency  of  classifications  made  by  human  judgment 
(i.e.,  to  determine  how  frequently  people  make  differing  classification  decisions 
based  on  the  same  information,  otherwise  known  as  “inter-coder  reliability”). 

•  Empirically  examine  the  relationships  among  the  measures  that  are  used  to 
calculate  additional  derived  measures.  Doing  so  can  ensure  that  important 
distinctions  are  not  overlooked  and  that  the  derived  measures  convey  their 
intended  meanings  (otherwise  known  as  “criterion  validity”). 


SP  2.2-1  Analyze  Measurement  Data 

Analyze  and  interpret  measurement  data.  [pais4.igio2.spio2] 


The  measurement  data  are  analyzed  as  planned,  additional  analyses 
are  conducted  as  necessary,  results  are  reviewed  with  relevant 
stakeholders,  and  necessary  revisions  for  future  analyses  are  noted. 

[PA154.IG102.SP102.N101] 
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Typical  Work  Products 

1.  Analysis  results  and  draft  reports  [PAi54.iGi02.sp102.w10i] 

Subpractices 

1 .  Conduct  initial  analyses,  interpret  the  results,  and  draw  preliminary 

conclusions.  [PA154.IG102.SP102.SubP101] 

The  results  of  data  analyses  are  rarely  self  evident.  Criteria  for  interpreting  the 
results  and  drawing  conclusions  should  be  stated  explicitly.  [PAi54.iGi02.sp102.subPi01.Ni0i] 

2.  Conduct  additional  measurement  and  analysis  as  necessary,  and 
prepare  results  for  presentation.  [PAi54.iGio2.spio2.sUbPio2] 

The  results  of  planned  analyses  may  suggest  (or  require)  additional,  unanticipated 
analyses.  In  addition,  they  may  identify  needs  to  refine  existing  measures,  to 
calculate  additional  derived  measures,  or  even  to  collect  data  for  additional 
primitive  measures  to  properly  complete  the  planned  analysis.  Similarly,  preparing 
the  initial  results  for  presentation  may  identify  the  need  for  additional, 
unanticipated  analyses.  [PAi54.iGi02.sp102.subPi02.Ni0i] 

3.  Review  the  initial  results  with  relevant  stakeholders. 

[PA154.IG102.SP102.SubP103] 

It  may  be  appropriate  to  review  initial  interpretations  of  the  results  and  the  way  in 
which  they  are  presented  before  disseminating  and  communicating  them  more 

Widely.  [PA154.IG102.SP102.SubP103.N101] 

Reviewing  the  initial  results  before  their  release  may  prevent  needless 
misunderstandings  and  lead  to  improvements  in  the  data  analysis  and 
presentation.  [PAi54.iGi02.sp102.subPi03.Ni02] 

Relevant  stakeholders  with  whom  reviews  may  be  conducted  include  intended 
end  users  and  sponsors,  as  well  as  data  analysts  and  data  providers. 

[PA154.IG102.SP102.SubP103.N103] 

4.  Refine  criteria  for  future  analyses.  [PAi54.iGio2.spio2.sUbPio4] 

Valuable  lessons  that  can  improve  future  efforts  are  often  learned  from  conducting 
data  analyses  and  preparing  results.  Similarly,  ways  to  improve  measurement 
specifications  and  data  collection  procedures  may  become  apparent,  as  may 
ideas  for  refining  identified  information  needs  and  objectives. 

[PA154.IG102.SP102.SubP104.N101] 


SP  2.3-1  Store  Data  and  Results 

Manage  and  store  measurement  data,  measurement 
specifications,  and  analysis  results,  [pm54.igio2.spw3] 
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Storing  measurement-related  information  enables  the  timely  and  cost- 
effective  future  use  of  historical  data  and  results.  The  information  also  is 
needed  to  provide  sufficient  context  for  interpretation  of  the  data, 
measurement  criteria,  and  analysis  results,  [pai54.igio2.spio3.nioi] 

Information  stored  typically  includes  the  following:  [PAi54.iGi02.sp103.Ni02] 

•  Measurement  plans 

•  Specifications  of  measures 

•  Sets  of  data  that  have  been  collected 

•  Analysis  reports  and  presentations 

The  stored  information  contains  or  references  the  information  needed  to 
understand  and  interpret  the  measures  and  assess  them  for 
reasonableness  and  applicability  (e.g.,  measurement  specifications 
used  on  different  projects  when  comparing  across  projects). 

[PA154.IG102.SP103.N103] 


Data  sets  for  derived  measures  typically  can  be  recalculated  and  need 
not  be  stored.  However,  it  may  be  appropriate  to  store  summaries 
based  on  derived  measures  (e.g.,  charts,  tables  of  results,  or  report 

prOSe).  [PA154.IG102.SP103.N104] 

Interim  analysis  results  need  not  be  stored  separately  if  they  can  be 
efficiently  reconstructed,  [pai54.igio2.spio3.nio5] 

Projects  may  choose  to  store  project-specific  data  and  results  in  a 
project-specific  repository.  When  data  are  shared  more  widely  across 
projects,  the  data  may  reside  in  the  organization’s  measurement 

repository.  [PA154.IG102.SP103.N106] 

Refer  to  the  Establish  the  Organization’s  Measurement  Repository 
specific  practice  of  the  Organizational  Process  Definition  process  area 
for  more  information  about  establishing  the  organization’s  measurement 

repository.  [PA154.IG102.SP103.N106.R101] 

Refer  to  the  Configuration  Management  process  area  for  information  on 
managing  measurement  work  products,  [pais4.igio2.spio3.nio6.rio2] 

Typical  Work  Products 

1 .  Stored  data  inventory  [PAi54.iGi02.sp103.w10i] 

Subpractices 

1 .  Review  the  data  to  ensure  their  completeness,  integrity,  accuracy, 
and  currency.  [PAi54.iGio2.spio3.subPioi] 

2.  Make  the  stored  contents  available  for  use  only  by  appropriate 
groups  and  personnel.  [PAi54.iGio2.spio3.subPio2] 
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3.  Prevent  the  stored  information  from  being  used  inappropriately. 

[PA154.IG102.SP103.SubP103] 


Examples  of  ways  to  prevent  inappropriate  use  of  the  data  and  related  information 
include  controlling  access  to  data  and  educating  people  on  the  appropriate  use  of 

data.  [PA154.IG102.SP103.SubP103.N101] 


Examples  of  inappropriate  use  include  the  following:  [PAi54.iGio2.sp103.subPio3.Nio2] 

•  Disclosure  of  information  that  was  provided  in  confidence 

•  Faulty  interpretations  based  on  incomplete,  out-of-context,  or  otherwise 
misleading  information 

•  Measures  used  to  improperly  evaluate  the  performance  of  people  or  to  rank 
projects 

•  Impugning  the  integrity  of  specific  individuals 


SP  2.4-1  Communicate  Results 

Report  results  of  measurement  and  analysis  activities  to  all 
relevant  stakeholders,  [pais4.igio2.spw4] 


The  results  of  the  measurement  and  analysis  process  are 
communicated  to  relevant  stakeholders  in  a  timely  and  usable  fashion 
to  support  decision  making  and  assist  in  taking  corrective  action. 

[PA154.IG102.SP104.N101] 


Relevant  stakeholders  include  intended  users,  sponsors,  data  analysts, 
and  data  providers,  [pais4.igio2.spio4.nio2] 

Typical  Work  Products 

1 .  Delivered  reports  and  related  analysis  results  [PAi54.iGi02.sp104.w10i] 

2.  Contextual  information  or  guidance  to  aid  in  the  interpretation  of 
analysis  results  [PAi54.iGi02.sp104.w102] 

Subpractices 

1 .  Keep  relevant  stakeholders  apprised  of  measurement  results  on  a 
timely  basis.  [PAi54.iGio2.spio4.subPioi] 

Measurement  results  are  communicated  in  time  to  be  used  for  their  intended 
purposes.  Reports  are  unlikely  to  be  used  if  they  are  distributed  with  little  effort  to 
follow  up  with  those  who  need  to  know  the  results.  [PAi54.iGio2.sp104.subPio1.Nioi] 

To  the  extent  possible  and  as  part  of  the  normal  way  they  do  business,  users  of 
measurement  results  are  kept  personally  involved  in  setting  objectives  and 
deciding  on  plans  of  action  for  measurement  and  analysis.  The  users  are  regularly 
kept  apprised  of  progress  and  interim  results.  [PAi54.iGi02.sp104.subPi01.Ni02] 
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Refer  to  the  Project  Monitoring  and  Control  process  area  for  more 
information  on  the  use  of  measurement  results. 

[PA154.IG102.SP104.SubP101.N102.R101] 

2.  Assist  relevant  stakeholders  in  understanding  the  results. 

[PA154.IG102.SP104.SubP102] 

Results  are  reported  in  a  clear  and  concise  manner  appropriate  to  the 
methodological  sophistication  of  the  relevant  stakeholders.  They  are 
understandable,  easily  interpretable,  and  clearly  tied  to  identified  information 
needs  and  objectives.  [PAi54.iGio2.sp104.subPio2.Nioi] 

The  data  are  often  not  self  evident  to  practitioners  who  are  not  measurement 
experts.  Measurement  choices  should  be  explicitly  clear  about  the  following: 

[PA154.IG102.SP104.SubP102.N102] 

•  How  and  why  the  base  and  derived  measures  were  specified 

•  How  the  data  were  obtained 

•  How  to  interpret  the  results  based  on  the  data  analysis  methods  that  were  used 

•  How  the  results  address  their  information  needs 

Examples  of  actions  to  assist  in  understanding  of  results  include  the  following: 

[PA154.IG102.SP104.SubP102.N103] 

•  Discussing  the  results  with  the  relevant  stakeholders 

•  Providing  a  transmittal  memo  that  provides  background  and  explanation 

•  Briefing  users  on  the  results 

•  Providing  training  on  the  appropriate  use  and  understanding  of  measurement 
results 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  measurement  and  analysis 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area,  igpiozi 
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GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  measurement  and  analysis  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  aligning 
measurement  objectives  and  activities  with  identified  information  needs 
and  objectives  and  for  providing  measurement  results.  [pais4  elioi] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  measurement 
and  analysis  process.  igpio4i 


Elaboration: 

Typically,  this  plan  for  performing  the  measurement  and  analysis 
process  is  included  in  (or  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area,  [paisaelhs] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  measurement  and 
analysis  process,  developing  the  work  products,  and  providing  the 
services  of  the  process,  [gpios] 


Elaboration: 

Measurement  personnel  may  be  employed  full  time  or  part  time.  A 
measurement  group  may  or  may  not  exist  to  support  measurement 
activities  across  multiple  projects.  [pai54.elio4] 


Examples  of  other  resources  provided  include  the  following  tools:  [pai54.elios] 

•  Statistical  packages 

•  Packages  that  support  data  collection  over  networks 
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GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
measurement  and  analysis  process,  [gpiobi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  measurement  and 
analysis  process  as  needed.  [gpio7j 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pais4.elio7] 

•  Statistical  techniques 

•  Data  collection,  analysis,  and  reporting  processes 

•  Development  of  goal-related  measurements  (e.g.,  Goal  Question  Metric) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  measurement  and  analysis 
process  under  appropriate  levels  of  configuration  management. 

[GP109] 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pai54.elios] 

•  Specifications  of  base  and  derived  measures 

•  Data  collection  and  storage  procedures 

•  Base  and  derived  measurement  data  sets 

•  Analysis  results  and  draft  reports 

•  Data  analysis  tools 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  measurement 
and  analysis  process  as  planned.  igpi24] 
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Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [pai54.elh4] 

•  Establishing  measurement  objectives  and  procedures 

•  Assessing  measurement  data 

•  Providing  meaningful  feedback  to  those  responsible  for  providing  the  raw  data  on 
which  the  analysis  and  results  depend 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  measurement  and  analysis  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuoi 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA154.EL111] 

•  Percentage  of  projects  using  progress  and  performance  measures 

•  Percentage  of  measurement  objectives  addressed 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  measurement  and  analysis 
process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [gpu3] 

Elaboration: 

Examples  of  activities  reviewed  include  the  following:  [pai54.elh2] 

•  Aligning  measurement  and  analysis  activities 

•  Providing  measurement  results 

Examples  of  work  products  reviewed  include  the  following:  [pais4.elh3] 

•  Specifications  of  base  and  derived  measures 

•  Data  collection  and  storage  procedures 

•  Analysis  results  and  draft  reports 
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GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institution; 

Review  the  activities,  status,  and  results  of  the  measurement  and 
analysis  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 

alize  a  Defined  Process 

The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  measurement 
and  analysis  process,  [gpiuj 

Collect  Improvement  Information 

GG  4  Institution; 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  measurement  and  analysis  process  to  support  the  future  use 
and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GP  4.1 

Establish  Quantitative  Objectives  for  the  Process 

GP  4.2 

Establish  and  maintain  quantitative  objectives  for  the 
measurement  and  analysis  process  that  address  quality  and 
process  performance  based  on  customer  needs  and  business 
objectives,  [gpusi 

Stabilize  Subprocess  Performance 

GG  5  Institution; 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  measurement  and  analysis  process  to 
achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  [gpiwi 

alize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 
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GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  measurement  and  analysis 
process  in  fulfilling  the  relevant  business  objectives  of  the 
organization.  [GP1251 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  measurement  and  analysis  process.  [GP1211 
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DECISION  ANALYSIS  AND  RESOLUTION 

Support 


Purpose 


The  purpose  of  Decision  Analysis  and  Resolution  is  to  analyze  possible 
decisions  using  a  formal  evaluation  process  that  evaluates  identified 
alternatives  against  established  criteria,  [paimi 


Introductory  Notes 


The  Decision  Analysis  and  Resolution  process  area  involves 
establishing  guidelines  to  determine  which  issues  should  be  subjected 
to  a  formal  evaluation  process  and  then  applying  formal  evaluation 
processes  to  these  issues.  [pai56.nioij 

A  formal  evaluation  process  is  a  structured  approach  to  evaluating 
alternative  solutions  against  established  criteria  to  determine  a 
recommended  solution  to  address  an  issue.  A  formal  evaluation 
process  involves  the  following  actions:  [pai56.nh2] 

•  Establishing  the  criteria  for  evaluating  alternatives 

•  Identifying  alternative  solutions 

•  Selecting  methods  for  evaluating  alternatives 

•  Evaluating  the  alternative  solutions  using  the  established  criteria 
and  methods 

•  Selecting  recommended  solutions  from  the  alternatives  based  on 
the  evaluation  criteria 

Rather  than  using  the  phrase  “alternative  solutions  to  address  issues” 
each  time  it  is  needed,  we  will  use  one  of  two  shorter  phrases: 
“alternative  solutions”  or  “alternatives.”  [pai56.nh3] 

A  formal  evaluation  process  reduces  the  subjective  nature  of  the 
decision  and  has  a  higher  probability  of  selecting  a  solution  that  meets 
the  multiple  demands  of  the  relevant  stakeholders.  [pais6  nio2] 

While  the  primary  application  of  this  process  area  is  for  selected 
technical  concerns,  formal  evaluation  processes  can  also  be  applied  to 
many  nontechnical  issues,  particularly  when  a  project  is  being  planned. 
Issues  that  have  multiple  alternative  solutions  and  evaluation  criteria 
lend  themselves  to  a  formal  evaluation  process.  [pais6.nio3] 
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Trade  studies  of  equipment  or  software  are  typical  examples  of  formal  evaluation 
processes.  [pai56.nih] 


During  planning,  specific  issues  requiring  a  formal  evaluation  process 
are  identified.  Typical  issues  include  selection  among  architectural  or 
design  alternatives,  use  of  reusable  or  commercial  off-the-shelf  (COTS) 
components,  supplier  selection,  engineering  support  environments  or 
associated  tools,  test  environments,  and  logistics  and  production.  A 
formal  evaluation  process  can  also  be  used  to  address  a  make-or-buy 
decision,  the  development  of  manufacturing  processes,  the  selection  of 
distribution  locations,  and  other  decisions.  [pais6.nio4] 

Guidelines  are  created  for  deciding  when  to  use  formal  evaluation 
processes  to  address  unplanned  issues.  Guidelines  often  suggest  using 
formal  evaluation  processes  when  issues  are  associated  with  medium 
to  high  risks  or  when  issues  affect  the  ability  to  achieve  project 
objectives.  [pais6.nio6] 

Formal  evaluation  processes  can  vary  in  formality,  type  of  criteria,  and 
methods  employed.  Less  formal  decisions  can  be  analyzed  in  a  few 
hours,  use  only  a  few  criteria  (e.g.,  effectiveness  and  cost  to 
implement),  and  result  in  a  one-  or  two-page  report.  More  formal 
decisions  may  require  separate  plans,  months  of  effort,  meetings  to 
develop  and  approve  criteria,  simulations,  prototypes,  piloting,  and 
extensive  documentation.  [pai56.nio7] 

Both  numeric  and  non-numeric  criteria  can  be  used  in  a  formal 
evaluation  process.  Numeric  criteria  use  weights  to  reflect  the  relative 
importance  of  the  criteria.  Non-numeric  criteria  use  a  more  subjective 
ranking  scale  (e.g.,  high,  medium,  low).  More  formal  decisions  may 
require  a  full  trade  study.  [PAise.Nios] 

A  formal  evaluation  process  identifies  and  evaluates  alternative 
solutions.  The  eventual  selection  of  a  solution  may  involve  iterative 
activities  of  identification  and  evaluation.  Portions  of  identified 
alternatives  may  be  combined,  emerging  technologies  may  change 
alternatives,  and  the  business  situation  for  vendors  may  change  during 
the  evaluation  period.  [pai56.nio9] 

A  recommended  alternative  is  accompanied  by  documentation  of  the 
selected  methods,  criteria,  alternatives,  and  rationale  for  the 
recommendation.  The  documentation  is  distributed  to  the  relevant 
stakeholders;  it  provides  a  record  of  the  formal  evaluation  process  and 
rationale  that  is  useful  to  other  projects  that  encounter  a  similar  issue. 

[PA156.N1 10] 
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Related  Process  Areas 


Refer  to  the  Project  Planning  process  area  for  more  information  about 
general  planning  for  projects,  ipaisb.rwi] 

Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process.  The 
project’s  defined  process  includes  a  formal  evaluation  process  for  each 
selected  issue  and  incorporates  the  use  of  guidelines  for  applying  a 
formal  evaluation  process  to  unforeseen  issues.  [pais6.rio2] 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
identifying  and  mitigating  risks.  A  formal  evaluation  process  is  often 
used  to  address  issues  with  identified  medium  or  high  risks.  Selected 
solutions  typically  affect  risk  mitigation  plans.  [pais6.rio3] 


Specific  Goals 

SG  1  Evaluate  Alternatives  [PAise  icioi] 

Decisions  are  based  on  an  evaluation  of  alternatives  using  established 
criteria. 

Generic  Goals 

GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clio3.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkm.glioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GG  5  Institutionalize  an  Optimizing  Process  [cliob.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 

Practice-to-Goal  Relationship  Table 

SG  1  Evaluate  Alternatives  [paisb.igioi] 

SP  1.1-1  Establish  Guidelines  for  Decision  Analysis 

SP  1.2-1  Establish  Evaluation  Criteria 

SP  1 .3-1  Identify  Alternative  Solutions 

SP  1.4-1  Select  Evaluation  Methods 

SP  1.5-1  Evaluate  Alternatives 

SP  1.6-1  Select  Solutions 

GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1  Perform  Base  Practices 

GG  2  Institutionalize  a  Managed  Process  [clio3.ghoi] 

GP  2.1  Establish  an  Organizational  Policy 

GP  2.2  Plan  the  Process 

GP  2.3  Provide  Resources 

GP  2.4  Assign  Responsibility 

GP  2.5  Train  People 

GP  2.6  Manage  Configurations 

GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

GP  2.8  Monitor  and  Control  the  Process 

GP  2.9  Objectively  Evaluate  Adherence 

GP  2.10  Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize  a  Defined  Process  [clio4.glioi] 

GP3.1  Establish  a  Defined  Process 

GP  3.2  Collect  Improvement  Information 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [clios.glioi] 

GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

GP  4.2  Stabilize  Subprocess  Performance 

GG  5  Institutionalize  an  Optimizing  Process  [cliobglioi] 

GP  5.1  Ensure  Continuous  Process  Improvement 

GP  5.2  Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 

SG  1  Evaluate  Alternatives 

Decisions  are  based  on  an  evaluation  of  alternatives  using  established 
criteria.  [pais6.igioi] 

Issues  requiring  a  formal  evaluation  process  may  be  identified  during 
any  phase  of  a  product  or  project  life  cycle.  The  objective  should  be  to 
identify  issues  as  early  as  possible  to  maximize  the  time  available  to 
resolve  the  issue,  [pais6.igioi.nioi] 
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SP  1.1-1  Establish  Guidelines  for  Decision  Analysis 

Establish  and  maintain  guidelines  to  determine  which  issues  are 
subject  to  a  formal  evaluation  process,  ipm56.igioi.spwi] 


Not  every  decision  is  significant  enough  to  require  a  formal  evaluation 
process.  The  choice  between  the  trivial  and  the  truly  important  will  be 
unclear  without  explicit  guidance.  Whether  a  decision  is  significant  or 
not  is  dependent  on  the  project  and  circumstances,  and  is  determined 
by  the  established  guidelines,  [pai56.igioi.spioi.nioi] 

Typical  guidelines  for  determining  when  to  require  a  formal  evaluation 
process  include  the  following:  [pai56.igioi.spioi.nio2] 

•  When  a  decision  is  directly  related  to  topics  assessed  as  being  of 
medium  or  high  risk 

•  When  a  decision  is  related  to  changing  work  products  under 
configuration  management 

•  When  a  decision  would  cause  schedule  delays  over  a  certain 
percentage  or  specific  amount  of  time 

•  When  a  decision  affects  the  ability  to  achieve  project  objectives 

•  When  the  costs  of  the  formal  evaluation  process  are  reasonable 
when  compared  to  the  decision’s  impact 

Refer  to  the  Risk  Management  process  area  for  more  information  about 
determining  which  issues  are  medium  or  high  risk,  [pais6.igioi.spioi.nw2.rioi] 


Examples  of  when  to  use  a  formal  evaluation  process  include  the  following: 

[PA156.IG101.SP101.N103] 

•  On  material  procurement  when  20  percent  of  the  material  parts  constitute  80 
percent  of  the  total  material  costs 

•  On  design-implementation  decisions  when  technical  performance  failure  may 
cause  a  catastrophic  failure  (e.g.,  safety  of  flight  item) 

•  On  decisions  with  the  potential  to  significantly  reduce  design  risk,  engineering 
changes,  cycle  time,  and  production  costs  (e.g.,  to  use  lithography  models  to 
assess  form  and  fit  capability  before  releasing  engineering  drawings  and 
production  builds) 


Typical  Work  Products 

1 .  Guidelines  for  when  to  apply  a  formal  evaluation  process 

[PA156.IG101.SP101.W101] 

Subpractices 

1.  Establish  guidelines.  [PAi56.iGioi.spioi.subPioi] 

2.  Incorporate  the  use  of  the  guidelines  into  the  defined  process 
where  appropriate.  [PAi56.iGioi.spioi.subPio2] 


502 


Support,  Decision  Analysis  and  Resolution 


CMMI-SW,  vl.1 
Continuous  Representation 


Refer  to  the  Integrated  Project  Management  process  area  for  more 
information  about  establishing  the  project’s  defined  process. 

[PA156.IG101.SP101.SubP102.R101] 


SP  1.2-1  Establish  Evaluation  Criteria 

Establish  and  maintain  the  criteria  for  evaluating  alternatives,  and 
the  relative  ranking  of  these  criteria,  ipai56.igwi.spw3] 


The  evaluation  criteria  provide  the  basis  for  evaluating  alternative 
solutions.  The  criteria  are  ranked  so  that  the  highest  ranked  criteria 
exert  the  most  influence  on  the  evaluation,  [pai56.igioi.spio3.nioi] 

This  process  area  is  referenced  by  many  other  process  areas  in  the 
model,  and  there  are  many  contexts  in  which  a  formal  evaluation 
process  can  be  used.  Therefore,  in  some  situations  you  may  find  that 
criteria  have  already  been  defined  as  part  of  another  process.  This 
specific  practice  does  not  suggest  that  a  second  development  of  criteria 

be  conducted.  [PA156.IG101.SP103.N103] 

Document  the  evaluation  criteria  to  minimize  the  possibility  that 
decisions  will  be  second-guessed,  or  that  the  reason  for  making  the 
decision  will  be  forgotten.  Decisions  based  on  criteria  that  are  explicitly 
defined  and  established  remove  barriers  to  stakeholder  buy-in. 

[PA156.IG101.SP103.N102] 

Typical  Work  Products 

1 .  Documented  evaluation  criteria  [pai56.igioi.spio3.wioi] 

2.  Rankings  of  criteria  importance  [pai56.igioi.spio3.wio2] 

Subpractices 

1 .  Define  the  criteria  for  evaluating  alternative  solutions. 

[PA156.IG101.SP103.SubP101] 

Criteria  should  be  traceable  to  requirements,  scenarios,  business  case 
assumptions,  business  objectives,  or  other  documented  sources. 

[PA156.IG101.SP103.SubP101.N101] 

Types  of  criteria  to  consider  include  the  following:  [PAi56.iGi01.sp103.subPi01.Ni02] 

•  Technology  limitations 

•  Environmental  impact 

•  Risks 

•  Total  ownership  and  life-cycle  costs 

2.  Define  the  range  and  scale  for  ranking  the  evaluation  criteria. 

[PA156.IG101.SP103.SubP102] 
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Scales  of  relative  importance  for  evaluation  criteria  can  be  established  with  non¬ 
numeric  values  or  with  formulas  that  relate  the  evaluation  parameter  to  a 
numerical  weight.  [PAi56.iGio1.sp103.subPio2.Nioi] 

3.  Rank  the  criteria.  [PAi56.iGioi.spio3.subPio3] 

The  criteria  are  ranked  according  to  the  defined  range  and  scale  to  reflect  the 
needs,  objectives,  and  priorities  of  the  relevant  stakeholders. 

[PA156.IG101.SP103.SubP103.N101] 

4.  Assess  the  criteria  and  their  relative  importance.  [PAi56.iGioi.spio3.subPios] 

5.  Evolve  the  evaluation  criteria  to  improve  their  validity. 

[PA156.IG101.SP103.SubP106] 

6.  Document  the  rationale  for  the  selection  and  rejection  of  evaluation 
criteria.  [PAi56.iGioi.spio3.subPio4] 

Documentation  of  selection  criteria  and  rationale  may  be  needed  to  justify 
solutions  or  for  future  reference  and  use.  [PAi56.iGi01.sp103.subPi04.Ni0i] 


SP  1.3-1  Identify  Alternative  Solutions 

Identify  alternative  solutions  to  address  issues,  [paisb.igioi.spiov 


A  wider  range  of  alternatives  can  surface  by  soliciting  as  many 
stakeholders  as  practical  for  input.  Input  from  stakeholders  with  diverse 
skills  and  backgrounds  can  help  teams  identify  and  address 
assumptions,  constraints,  and  biases.  Brainstorming  sessions  may 
stimulate  innovative  alternatives  through  rapid  interaction  and  feedback. 
Sufficient  candidate  solutions  may  not  be  furnished  for  analysis.  As  the 
analysis  proceeds,  other  alternatives  should  be  added  to  the  list  of 
potential  candidate  solutions.  The  generation  and  consideration  of 
multiple  alternatives  early  in  a  decision  analysis  and  resolution  process 
increases  the  likelihood  that  an  acceptable  decision  will  be  made,  and 
that  consequences  of  the  decision  will  be  understood,  [pai56.igioi.spio4.nioi] 

Typical  Work  Products 

1.  Identified  alternatives  [pai56.igioi.spio4.wioi] 

Subpractices 

1.  Perform  a  literature  search.  [PAi56.iGioi.spio4.subPioi] 

A  literature  search  can  uncover  what  others  have  done  both  inside  and  outside 
the  organization.  It  may  provide  a  deeper  understanding  of  the  problem, 
alternatives  to  consider,  barriers  to  implementation,  existing  trade  studies,  and 
lessons  learned  from  similar  decisions.  [PAi56.iGioi.spio4.subPioi.Nioi] 

2.  Identify  alternatives  for  consideration  in  addition  to  those  that  may 
be  provided  with  the  issue.  [PAi56.iGioi.spio4.subPio2] 
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Evaluation  criteria  are  an  effective  starting  point  for  identifying  alternatives.  The 
evaluation  criteria  identify  the  priorities  of  the  relevant  stakeholders  and  the 
importance  of  technical  challenges.  [PAi56.iGio1.sp104.subPio2.Nioi] 

Combining  key  attributes  of  existing  alternatives  can  generate  additional  and 
sometimes  stronger  alternatives.  [PAi56.iGio1.sp104.subPio2.Nio2] 

Solicit  alternatives  from  relevant  stakeholders.  Brainstorming  sessions,  interviews, 
and  working  groups  can  be  used  effectively  to  uncover  alternatives. 

[PA156.IG101.SP104.SubP102.N103] 

3.  Document  the  proposed  alternatives.  [PAi56.iGioi.spio4.subPio3] 


SP  1.4-1  Select  Evaluation  Methods 

Select  the  evaluation  methods.  [pai56.igioi.spio2j 


Methods  for  evaluating  alternative  solutions  against  established  criteria 
can  range  from  simulations  to  the  use  of  probabilistic  models  and 
decision  theory.  These  methods  need  to  be  carefully  selected.  The  level 
of  detail  of  a  method  should  be  commensurate  with  cost,  schedule, 
performance,  and  risk  impacts,  [pai56.igioi.spio2.nioi] 

While  many  problems  may  need  only  one  evaluation  method,  some 
problems  may  require  multiple  methods.  For  instance,  simulations  may 
augment  a  trade  study  to  determine  which  design  alternative  best 
meets  a  given  criterion,  [pai56.igioi.spio2.nio2] 

Typical  Work  Products 

1.  Selected  evaluation  methods  [pai56.igioi.spio2.wioi] 

Subpractices 

1 .  Select  the  methods  based  on  the  purpose  for  analyzing  a  decision 
and  on  the  availability  of  the  information  used  to  support  the 

method.  [PA156.IG101.SP102.SubP101] 


For  example,  the  methods  used  for  evaluating  a  technical  solution  when 
requirements  are  weakly  defined  may  be  different  from  the  methods  used  when 
the  requirements  are  well  defined.  [PAi56.iGi01.sp102.subPi01.Nioi] 


Typical  evaluation  methods  include  the  following:  [PAi56.iGi01.sp102.subPi01.Ni02] 

•  Simulations 

•  Engineering  studies 

•  Manufacturing  studies 

•  Cost  studies 

•  Business  opportunity  studies 


Support,  Decision  Analysis  and  Resolution 


505 


CMMI-SW,  vl.1 
Continuous  Representation 


•  Surveys 

•  Extrapolations  based  on  field  experience  and  prototypes 

•  User  review  and  comment 

•  Testing 

2.  Select  evaluation  methods  based  on  their  ability  to  focus  on  the 
issues  at  hand  without  being  overly  influenced  by  side  issues. 

[PA156.IG101  ,SP102.SubP102] 

Results  of  simulations  can  be  skewed  by  random  activities  in  the  solution  that  are 
not  directly  related  to  the  issues  at  hand.  [PAi56.iGi01.sp102.subPi02.Ni0i] 

3.  Determine  the  measures  needed  to  support  the  evaluation  method. 

[PA156.IG101.SP102.SubP103] 

Consider  the  impact  on  cost,  schedule,  performance,  and  risks. 

[PA156.IG101.SP102.SubP103.N101] 


SP  1.5-1  Evaluate  Alternatives 

Evaluate  alternative  solutions  using  the  established  criteria  and 

methods.  [PA156.IG101.SPW5] 


Evaluating  alternative  solutions  involves  analysis,  discussion,  and 
review.  Iterative  cycles  of  analysis  are  sometimes  necessary. 
Supporting  analyses,  experimentation,  prototyping,  or  simulations  may 
be  needed  to  substantiate  scoring  and  conclusions,  [pai56.igioi.spio5.nioi] 

Often,  the  relative  importance  of  criteria  is  imprecise  and  the  total  effect 
on  a  solution  is  not  apparent  until  after  the  analysis  is  performed.  In 
cases  where  the  resulting  scores  differ  by  relatively  small  amounts,  the 
best  selection  among  alternative  solutions  may  not  be  clearcut. 
Challenges  to  criteria  and  assumptions  should  be  encouraged. 

[PA156.IG101.SP105.N102] 

Typical  Work  Products 

1 .  Evaluation  results  [pai56.igioi.spio5.wioi] 

Subpractices 

1.  Evaluate  the  proposed  alternative  solutions  using  the  established 
evaluation  criteria  and  selected  methods.  [PAise.icioi.spios.subPioi] 

2.  Evaluate  the  assumptions  related  to  the  evaluation  criteria  and  the 
evidence  that  supports  the  assumptions.  [PAi56.iGioi.spio5.subPio2] 

3.  Evaluate  whether  uncertainty  in  the  values  for  alternative  solutions 
affects  the  evaluation  and  address  as  appropriate. 

[PA156.IG101.SP105.SubP103] 
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For  instance,  if  the  score  can  vary  between  two  values,  is  the  difference 
significant  enough  to  make  a  difference  in  the  final  solution  set?  Does  the 
variation  in  score  represent  a  high  risk?  To  address  these  concerns,  simulations 
may  be  run,  further  studies  may  be  performed,  or  evaluation  criteria  may  be 
modified,  among  other  things.  [PAi56.iGi01.sp105.subPi03.Ni0i] 

4.  Perform  simulations,  modeling,  prototypes,  and  pilots  as  necessary 
to  exercise  the  evaluation  criteria,  methods,  and  alternative 

SOlUtiOnS.  [PA156.IG101  .SP105.SubP104] 

Untested  criteria,  their  relative  importance,  and  supporting  data  or  functions  may 
cause  the  validity  of  solutions  to  be  questioned.  Criteria  and  their  relative  priorities 
and  scales  can  be  tested  with  trial  runs  against  a  set  of  alternatives.  These  trial 
runs  of  a  select  set  of  criteria  allow  for  the  evaluation  of  the  cumulative  impact  of 
the  criteria  on  a  solution.  If  the  trials  reveal  problems,  different  criteria  or 
alternatives  might  be  considered  to  avoid  biases.  [PAi56.iGioi.spio5.subPio4.Nioi] 

5.  Consider  new  alternative  solutions,  criteria,  or  methods  if  the 
proposed  alternatives  do  not  test  well;  repeat  the  evaluations  until 
alternatives  do  test  well.  [PAi56.iGioi.spios.subPio5] 

6.  Document  the  results  of  the  evaluation.  [PAise.iGioi.spios.subPioe] 

Document  the  rationale  for  the  addition  of  new  alternatives  or  methods  and 
changes  to  criteria,  as  well  as  the  results  of  interim  evaluations. 

[PA156.IG101.SP105.SubP106.N101] 


SP  1.6-1  Select  Solutions 

Select  solutions  from  the  alternatives  based  on  the  evaluation 
criteria,  [pai56.igioi.spw6] 

Selecting  solutions  involves  weighing  the  results  from  the  evaluation  of 
alternatives.  Risks  associated  with  implementation  of  the  solutions  must 
be  assessed,  [pai56.igioi.spio6.nioi] 

Typical  Work  Products 

1 .  Recommended  solutions  to  address  significant  issues 

[PA156.IG101.SP106.W101] 

Subpractices 

1.  Assess  the  risks  associated  with  implementing  the  recommended 

SOlUtiOn.  [PA156.IG101  ,SP106.SubP101] 

Refer  to  the  Risk  Management  process  area  for  more  information 
about  identifying  and  managing  risks.  [PAi56.iGioi.spw6.subPioi.Rioi] 
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Decisions  must  often  be  made  with  incomplete  information.  There  can  be 
substantial  risk  associated  with  the  decision  because  of  having  incomplete 
information.  [PAi56.iGioi.spio6.subPioi.Nioi] 

When  decisions  must  be  made  according  to  a  specific  schedule,  time  and 
resources  may  not  be  available  for  gathering  complete  information.  Consequently, 
risky  decisions  made  with  incomplete  information  may  require  re-analysis  later. 
Identified  risks  should  be  monitored.  [PAi56.iGioi.spio6.subPioi.Nio2] 

2.  Document  the  results  and  rationale  for  the  recommended  solution. 

[PA156.IG101.SP106.SubP102] 


It  is  important  to  record  both  why  a  solution  is  selected  and  why  another  solution 
was  rejected.  [PAi56.iGio1.sp106.subPio2.Nioi] 


Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  decision  analysis  and  resolution 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  decision  analysis  and  resolution  process.  [gpio3i 


Elaboration: 

This  policy  establishes  organizational  expectations  for  selectively 
analyzing  possible  decisions  using  a  formal  evaluation  process  that 
evaluates  identified  alternatives  against  established  criteria.  The  policy 
should  also  provide  guidance  on  which  decisions  require  a  formal 
evaluation  process.  [pai56.elioi] 
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GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  decision 
analysis  and  resolution  process,  [gpimi 


Elaboration: 

Typically,  this  plan  for  performing  the  decision  analysis  and  resolution 
process  is  included  in  (or  is  referenced  by)  the  project  plan,  which  is 
described  in  the  Project  Planning  process  area,  [paisb.elho] 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  decision  analysis 
and  resolution  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpios] 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools:  [pais6.elio2] 

•  Simulators  and  modeling  tools 

•  Prototyping  tools 

•  Tools  for  conducting  surveys 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
decision  analysis  and  resolution  process,  [gpiosi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  decision  analysis 
and  resolution  process  as  needed,  igpiot] 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pais6.elio3] 

•  Formal  decision  analysis 

•  Methods  for  evaluating  alternative  solutions  against  criteria 
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GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  decision  analysis  and 
resolution  process  under  appropriate  levels  of  configuration 
management,  [gpioqi 

Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais6.elio4] 

•  Guidelines  for  when  to  apply  a  formal  evaluation  process 

•  Evaluation  reports  containing  recommended  solutions 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  decision 
analysis  and  resolution  process  as  planned.  [gpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [paisb.elios] 

•  Establishing  guidelines  for  which  issues  are  subject  to  a  formal  evaluation  process 

•  Establishing  evaluation  criteria 

•  Identifying  and  evaluating  alternatives 

•  Selecting  evaluation  methods 

•  Selecting  solutions 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  decision  analysis  and  resolution  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpuoi 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA156.EL105] 

•  Cost-to-benefit  ratio  of  using  formal  evaluation  processes 
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GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  decision  analysis  and 
resolution  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance.  igpu3] 


Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai56.elio6] 

•  Evaluating  alternatives  using  established  criteria  and  methods 


Examples  of  work  products  reviewed  include  the  following:  [pai56.elios] 

•  Guidelines  for  when  to  apply  a  formal  evaluation  process 

•  Evaluation  reports  containing  recommended  solutions 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  decision  analysis 
and  resolution  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  decision 
analysis  and  resolution  process,  /g piui 

Collect  Improvement  Information 

GG  4  Institution 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  decision  analysis  and  resolution  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  decision 
analysis  and  resolution  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GPU  8] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  decision  analysis  and  resolution 
process  to  achieve  the  established  quantitative  quality  and 
process-performance  objectives,  [gpiwi 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  decision  analysis  and 
resolution  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization,  [gpusj 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  decision  analysis  and  resolution  process.  [GP121] 
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CAUSAL  ANALYSIS  AND  RESOLUTION 

Support 


Purpose 


The  purpose  of  Causal  Analysis  and  Resolution  is  to  identify  causes  of 
defects  and  other  problems  and  take  action  to  prevent  them  from 
occurring  in  the  future,  [paissj 


Introductory  Notes 


The  Causal  Analysis  and  Resolution  process  area  involves  the 
following:  [paiss.nioi] 

•  Identifying  and  analyzing  causes  of  defects  and  other  problems 

•  Taking  specific  actions  to  remove  the  causes  and  prevent  the 
occurrence  of  those  types  of  defects  and  problems  in  the  future 

Causal  analysis  and  resolution  improves  quality  and  productivity  by 
preventing  the  introduction  of  defects  into  a  product.  Reliance  on 
detecting  defects  after  they  have  been  introduced  is  not  cost  effective.  It 
is  more  effective  to  prevent  defects  from  being  introduced  by  integrating 
causal  analysis  and  resolution  activities  into  each  phase  of  the  project. 

[PA155.N102] 


Since  defects  and  problems  may  have  been  previously  encountered  on 
other  projects  or  in  earlier  phases  or  tasks  of  the  current  project,  causal 
analysis  and  resolution  activities  are  a  mechanism  for  communicating 
lessons  learned  among  projects.  [paiss.nkb] 

The  types  of  defects  and  other  problems  encountered  are  analyzed  to 
identify  any  trends.  Based  on  an  understanding  of  the  defined  process 
and  how  it  is  implemented,  the  root  causes  of  the  defects  and  the  future 
implications  of  the  defects  are  determined,  [paiss.nkm] 

Causal  analysis  may  also  be  performed  on  problems  unrelated  to 
defects.  For  example,  causal  analysis  may  be  used  to  improve  quality 
attributes  such  as  cycle  time.  Improvement  proposals,  simulations, 
dynamic  systems  models,  engineering  analyses,  new  business 
directives,  or  other  items  may  initiate  such  analysis,  [paiss.nios] 

Sometimes  it  may  be  impractical  to  perform  causal  analysis  on  all 
defects.  In  these  cases,  tradeoffs  are  made  between  estimated 
investments  and  estimated  returns  in  quality,  productivity,  and  cycle 
time,  and  defect  targets  are  selected,  [paiss  niob] 
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A  measurement  process  should  already  be  in  place.  The  defined 
measures  can  be  used,  though  in  some  instances  new  measures  may 
be  needed  to  analyze  the  effects  of  the  process  change,  [paiss.nioz] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results,  [paiss.nio7.rioi] 

Causal  Analysis  and  Resolution  activities  provide  a  mechanism  for 
projects  to  evaluate  their  processes  at  the  local  level  and  look  for 
improvements  that  can  be  implemented,  [paiss.nios] 

When  improvements  are  judged  to  be  effective,  the  information  is 
extended  to  the  organizational  level,  [paiss.nioss] 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  improving  organizational  level  processes 
through  proposed  improvements  and  action  proposals,  [paiss.nioo.riov 

The  informative  material  in  this  process  area  is  written  with  the 
assumption  that  the  specific  practices  are  applied  to  a  quantitatively 
managed  process.  The  specific  practices  of  this  process  area  may  be 
applicable,  but  with  reduced  value,  if  the  assumption  is  not  met. 

[PA155.N110] 


See  the  definitions  of  “stable  process”  and  “common  cause  of  process 
variation”  in  Appendix  C,  the  glossary,  [paiss.nui] 


Related  Process  Areas 


Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  the  analysis  of  process  performance  and  the  creation 
of  process  capability  measures  for  selected  project  processes,  [paiss.rioi] 

Refer  to  the  Organizational  Innovation  and  Deployment  process  area 
for  more  information  about  the  selection  and  deployment  of 
improvements  to  organizational  processes  and  technologies.  [paiss.rio2] 

Refer  to  the  Measurement  and  Analysis  process  area  for  more 
information  about  establishing  objectives  for  measurement  and 
analysis,  specifying  the  measures  and  analyses  to  be  performed, 
obtaining  and  analyzing  measures,  and  reporting  results.  ipais5.rio3] 
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SG  1  Determine  Causes  of  Defects  [paiss.igioi] 


Root  causes  of  defects  and  other  problems  are  systematically  determined. 


SG  2  Address  Causes  of  Defects  [paiss.igio2] 


Root  causes  of  defects  and  other  problems  are  systematically  addressed  to 
prevent  their  future  occurrence. 


Generic  Goals 


GG  1  Achieve  Specific  Goals  [clio2glioi] 

The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 

GG  2  Institutionalize  a  Managed  Process  [clio3.glioi] 

The  process  is  institutionalized  as  a  managed  process. 

GG  3  Institutionalize  a  Defined  Process  [clkmglioi] 

The  process  is  institutionalized  as  a  defined  process. 

GG  4  Institutionalize  a  Quantitatively  Managed  Process  [cliosglioi] 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 

GG  5  Institutionalize  an  Optimizing  Process  [clios.glioi] 

The  process  is  institutionalized  as  an  optimizing  process. 


Practice-to-Goal  Relationship  Table 

SG  1  Determine  Causes  of  Defects  [paiss.igioi] 

SP  1.1-1  Select  Defect  Data  for  Analysis 

SP  1.2-1  Analyze  Causes 

SG  2  Address  Causes  of  Defects  [paiss.igioi 

SP  2.1-1  Implement  the  Action  Proposals 
SP  2.2-1  Evaluate  the  Effect  of  Changes 

SP  2.3-1  Record  Data 
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GG  1  Achieve  Specific  Goals  [clio2.glioi] 

GP  1.1 

Perform  Base  Practices 

GG  2  Institutionalize 

a  Managed  Process  [clio3.ghoi] 

GP  2.1 

Establish  an  Organizational  Policy 

GP  2.2 

Plan  the  Process 

GP  2.3 

Provide  Resources 

GP  2.4 

Assign  Responsibility 

GP  2.5 

Train  People 

GP  2.6 

Manage  Configurations 

GP  2.7 

Identify  and  Involve  Relevant  Stakeholders 

GP  2.8 

Monitor  and  Control  the  Process 

GP  2.9 

Objectively  Evaluate  Adherence 

GP  2.10 

Review  Status  with  Higher  Level  Management 

GG  3  Institutionalize 

a  Defined  Process  [clioaglioi] 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Collect  Improvement  Information 

GG  4  Institutionalize 

a  Ouantitatively  Managed  Process  [clios.glioi] 

GP  4.1 

Establish  Ouantitative  Objectives  for  the  Process 

GP  4.2 

Stabilize  Subprocess  Performance 

GG  5  Institutionalize 

an  Optimizing  Process  [clio6.glioi] 

GP  5.1 

Ensure  Continuous  Process  Improvement 

GP  5.2 

Correct  Root  Causes  of  Problems 

Specific  Practices  by  Goal 


SG  1  Determine  Causes  of  Defects 


Root  causes  of  defects  and  other  problems  are  systematically  determined. 

[PA155.IG101] 

A  root  cause  is  a  source  of  a  defect  such  that  if  it  is  removed,  the  defect 
is  decreased  or  removed,  [paiss.igioi.nioi] 


SP  1.1-1  Select  Defect  Data  for  Analysis 

Select  the  defects  and  other  problems  for  analysis,  [paiss.igioi.spioi] 

Typical  Work  Products 

1 .  Defect  and  problem  data  selected  for  further  analysis 

[PA155.IG101.SP101.W101] 

Subpractices 

1 .  Gather  relevant  defect  data.  [PAiss.iGioi.spioi.subPioi] 
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Examples  of  relevant  defect  data  may  include  the  following:  [PAi55.iGio1.sp101.subPio1.Nioi] 

•  Project  management  problem  reports  requiring  corrective  action 

•  Defects  reported  by  the  customer 

•  Defects  reported  by  end  user 

•  Defects  found  in  peer  reviews 

•  Defects  found  in  testing 

•  Process  capability  problems 


Refer  to  the  Verification  process  area  for  more  information  about 
work  product  verification.  [PAiss.iGioi.spwi.subPioi.Nioi.Rioi] 

Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  statistical  management. 

[PA1SS.IG101.SP101.SubP101.N101.R102] 

2.  Determine  which  defects  and  other  problems  will  be  analyzed 
further.  [PAi55.iGioi.spioi.subPio2] 

When  determining  which  defects  to  analyze  further,  consider  the  impact  of  the 
defects,  the  frequency  of  occurrence,  the  similarity  between  defects,  the  cost  of 
analysis,  the  time  and  resources  needed,  safety  considerations,  etc. 

[PA155.IG101.SP101.SubP102.N101] 


Examples  of  methods  for  selecting  defects  and  other  problems  include  the 

following :  [PAI55.IGIOI .SPIOI .SubP102.N102] 

•  Pareto  analysis 

•  Histograms 

•  Process  capability  analysis 


SP  1.2-1  Analyze  Causes 

Perform  causal  analysis  of  selected  defects  and  other  problems 
and  propose  actions  to  address  them,  [paiss.igioi.spw2] 

The  purpose  of  this  analysis  is  to  develop  solutions  to  the  identified 
problems  by  analyzing  the  relevant  data  and  producing  action  proposals 
for  implementation,  [pai55.igioi.spio2.nioi] 

Typical  Work  Products 

1.  Action  proposal  [PAi55.iGi01.sp102.w10i] 

Subpractices 

1 .  Conduct  causal  analysis  with  the  people  who  are  responsible  for 
performing  the  task.  [PAi55.iGioi.spio2.subPioi] 
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Causal  analysis  is  performed  with  those  people  who  have  an  understanding  of  the 
selected  defect  or  problem  under  study,  typically  in  meetings.  The  people  who 
have  the  best  understanding  of  the  selected  defect  are  typically  those  responsible 
for  performing  the  task.  [PAi55.iGi01.sp102.subPi01.Ni02] 


Examples  of  when  to  perform  causal  analysis  include  the  following: 

[PA155.IG101.SP102.SubP101.N101] 

•  When  a  stable  process  does  not  meet  its  specified  quality  and  process- 
performance  objectives 

•  During  the  task,  if  and  when  problems  warrant  additional  meetings 

•  When  a  work  product  exhibits  an  unexpected  deviation  from  its  requirements 


Refer  to  the  Quantitative  Project  Management  process  area  for 
more  information  about  achieving  the  project’s  quality  and  process- 
performance  objectives.  [PAiss.iGi01.sp102.subPi01.Ni01.Ri0i] 

2.  Analyze  selected  defects  and  other  problems  to  determine  their 

root  causes.  [PA155.IG101.SP102.SubP102] 

Depending  on  the  type  and  number  of  defects,  it  may  make  sense  to  first  group 
the  defects  before  identifying  their  root  causes.  [PAi55.iGi01.sp102.subPi02.Ni02] 

Examples  of  methods  to  determine  root  causes  include  the  following: 

[PA155.IG101.SP102.SubP102.N101] 

•  Cause-and-effect  (fishbone)  diagrams 

•  Check  sheets 

3.  Group  the  selected  defects  and  other  problems  based  on  their  root 

causes.  [PA155.IG101.SP102.SubP103] 


Examples  of  cause  groups,  or  categories,  include  the  following: 

[PA155.IG101.SP102.SubP103.N101] 

•  Inadequate  training 

•  Breakdown  of  communications 

•  Not  accounting  for  all  details  of  the  task 

•  Making  mistakes  in  manual  procedures  (e.g.,  typing) 

•  Process  deficiency 


4.  Propose  and  document  actions  that  need  to  be  taken  to  prevent 
the  future  occurrence  of  similar  defects  or  other  problems. 

[PA155.IG101.SP102.SubP104] 
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Examples  of  proposed  actions  include  changes  to  the  following: 

[PA155.IG101.SP102.SubP104.N101] 

•  The  process  in  question 

•  Training 

•  Tools 

•  Methods 

•  Communications 

•  Work  products 

Examples  of  specific  actions  include  the  following:  [PAi55.iGi01.sp102.subPi04.Ni02] 

•  Providing  training  in  common  problems  and  techniques  for  preventing  them 

•  Changing  a  process  so  that  error-prone  steps  do  not  occur 

•  Automating  all  or  part  of  a  process 

•  Reordering  process  activities 

•  Adding  process  steps  to  prevent  defects,  such  as  task  kickoff  meetings  to  review 
common  defects  and  actions  to  prevent  them 


An  action  proposal  usually  documents  the  following:  [PAi55.iGi01.sp102.subPi04.Ni03] 

•  Originator  of  the  action  proposal 

•  Description  of  the  problem 

•  Description  of  the  defect  cause 

•  Defect  cause  category 

•  Phase  when  the  problem  was  introduced 

•  Phase  when  the  defect  was  identified 

•  Description  of  the  action  proposal 

•  Action  proposal  category 

SG  2  Address  Causes  of  Defects 


Root  causes  of  defects  and  other  problems  are  systematically  addressed  to 
prevent  their  future  occurrence.  [paiss.igio2] 

Projects  operating  according  to  a  well-defined  process  will 
systematically  analyze  the  operation  where  problems  still  occur  and 
implement  process  changes  to  eliminate  root  causes  of  selected 

problems.  [PA155.IG102.N101] 
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SP  2.1-1  Implement  the  Action  Proposals 

Implement  the  selected  action  proposals  that  were  developed  in 
causal  analysis.  paiss.igio2.spwi] 

Action  proposals  describe  the  tasks  necessary  to  remove  the  root 
causes  of  the  analyzed  defects  or  problems  and  avoid  their 
reoccurrence,  [pais5.igio2.spioi.nioi] 

Only  changes  that  prove  to  be  of  value  should  be  considered  for  broad 
implementation,  [pai55.igio2.spioi.nio2] 

Typical  Work  Products 

1.  Action  proposals  selected  for  implementation  [pai55.igio2.spioi.wioi] 

2.  Improvement  proposals  [pai55.igio2.spioi.wio2] 

Subpractices 

1 .  Analyze  the  action  proposals  and  determine  their  priorities. 

[PA155.IG102.SP101.SubP101] 

Criteria  for  prioritizing  action  proposals  include  the  following: 

[PA155.IG102.SP101.SubP101.N101] 

•  Implications  of  not  addressing  the  defects 

•  Cost  to  implement  process  improvements  to  prevent  the  defects 

•  Expected  impact  on  quality 

2.  Select  the  action  proposals  that  will  be  implemented. 

[PA155.IG102.SP101.SubP102] 

3.  Create  action  items  for  implementing  the  action  proposals. 

[PA155.IG102.SP101.SubP103] 

Examples  of  information  provided  in  an  action  item  include  the  following: 

[PA155.IG102.SP101.SubP103.N101] 

•  Person  responsible  for  implementing  it 

•  Description  of  the  areas  affected  by  it 

•  People  who  are  to  be  kept  informed  of  its  status 

•  Next  date  that  status  will  be  reviewed 

•  Rationale  for  key  decisions 

•  Description  of  implementation  actions 

•  Time  and  cost  for  identifying  the  defect  and  correcting  it 

•  Estimated  cost  of  not  fixing  the  problem 


To  implement  the  action  proposals,  the  following  tasks  must  be  done: 

[PA155.IG102.SP101.SubP103.N102] 
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•  Make  assignments 

•  Coordinate  the  persons  doing  the  work 

•  Review  the  results 

•  Track  the  action  items  to  closure 

Experiments  may  be  conducted  for  particularly  complex  changes. 

[PA155.IG102.SP101.SubP103.N103] 

Examples  of  experiments  include  the  following:  [PAi55.iGio2.sp101.subPio3.Nio5] 

•  Using  a  temporarily  modified  process 

•  Using  a  new  tool 


Action  items  may  be  assigned  to  members  of  the  causal  analysis  team,  members 
of  the  project  team,  or  other  members  of  the  organization.  [PAi55.iGi02.sp101.subPi03.Ni04] 

4.  Identify  and  remove  similar  defects  that  may  exist  in  other 
processes  and  work  products.  [PAi55.iGio2.spioi.subPio4] 

5.  Identify  and  document  improvement  proposals  for  the 
organization’s  set  of  standard  processes.  [PAi55.iGio2.spioi.subPio5] 

Refer  to  the  Organizational  Innovation  and  Deployment  process 
area  for  more  information  about  the  selection  and  deployment  of 
improvement  proposals  for  the  organization’s  set  of  standard 
processes.  [PAi5s.iGi02.sp101.subPi0s.Ri0i] 


SP  2.2-1  Evaluate  the  Effect  of  Changes 

Evaluate  the  effect  of  changes  on  process  performance. 

[PA  155.IG102.SP102] 

Refer  to  the  Quantitative  Project  Management  process  area  for  more 
information  about  analyzing  process  performance  and  creating  process 
capability  measures  for  selected  processes,  [paiss.igio2.spio2.rioi] 

Once  the  changed  process  is  deployed  across  the  project,  the  effect  of 
the  changes  must  be  checked  to  gather  evidence  that  the  process 
change  has  corrected  the  problem  and  improved  performance. 

[PA155.IG102.SP102.N101] 

Typical  Work  Products 

1 .  Measures  of  performance  and  performance  change 

[PA155.IG102.SP102.W101] 

Subpractices 

1 .  Measure  the  change  in  the  performance  of  the  project's  defined 
process  as  appropriate.  [PAi55.iGio2.spio2.subPioi] 
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This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  process  performance  and  by  how  much,  [PAi55.iGio2.sp102.subPim.Nioi] 


An  example  of  a  change  in  the  performance  of  the  project’s  defined  design 
process  would  be  the  change  in  the  defect  density  of  the  design  documentation, 
as  statistically  measured  through  peer  reviews  before  and  after  the  improvement 
has  been  made.  On  a  statistical  process  control  chart,  this  would  be  represented 
by  a  change  in  the  mean.  [PAi55.iGio2.sp102.subPio1.Nio2] 


2.  Measure  the  capability  of  the  project's  defined  process  as 
appropriate.  [PAi55.iGio2.spio2.subPio2] 

This  subpractice  determines  whether  the  selected  change  has  positively 
influenced  the  ability  of  the  process  to  meet  its  quality  and  process-performance 
objectives,  as  determined  by  relevant  stakeholders.  [PAi55.iGi02.sp102.subPi02.Ni0i] 


An  example  of  a  change  in  the  capability  of  the  project’s  defined  design  process 
would  be  a  change  in  the  ability  of  the  process  to  stay  within  its  process- 
specification  boundaries.  This  can  be  statistically  measured  by  calculating  the 
range  of  the  defect  density  of  design  documentation,  as  collected  in  peer  reviews 
before  and  after  the  improvement  has  been  made.  On  a  statistical  process  control 
chart,  this  would  be  represented  by  lowered  control  limits.  [PAi55.iGi02.sp102.subPi02.Ni02] 


SP  2.3-1  Record  Data 

Record  causal  analysis  and  resolution  data  for  use  across  the 
project  and  organization,  [paiss.igw2.spw3] 


Data  are  recorded  so  that  other  projects  and  organizations  can  make 
appropriate  process  changes  and  achieve  similar  results. 

[PA155.IG102.SP103.N101] 

Record  the  following:  [PAi55.iGi02.sp103.Ni02] 

•  Data  on  defects  and  other  problems  that  were  analyzed 

•  Rationale  for  decisions 

•  Action  proposals  from  causal  analysis  meetings 

•  Action  items  resulting  from  action  proposals 

•  Cost  of  the  analysis  and  resolution  activities 

•  Measures  of  changes  to  the  performance  of  the  defined  process 
resulting  from  resolutions 

Typical  Work  Products 

1 .  Causal  analysis  and  resolution  records  [PAi55.iGi02.sp103.w10i] 
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Generic  Practices  by  Goal 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  causal  analysis  and  resolution 
process  to  develop  work  products  and  provide  services  to  achieve 
the  specific  goals  of  the  process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  causal  analysis  and  resolution  process.  [gpio3] 


Elaboration: 

This  policy  establishes  organizational  expectations  for  identifying  and 
systematically  addressing  root  causes  of  defects  and  other  problems. 

[PA155.EL101] 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  causal  analysis 
and  resolution  process,  /gpw; 


Elaboration: 

This  plan  for  performing  the  causal  analysis  and  resolution  process 
differs  from  the  action  proposals  and  associated  action  plans  described 
in  the  specific  practice  in  this  process  area.  The  plan  called  for  in  this 
generic  process  would  address  the  organization’s  overall  causal 
analysis  and  resolution  process.  In  contrast,  the  process  action 
proposals  and  associated  action  plans  address  the  activities  needed  to 
remove  the  root  cause  under  study,  [paiss.elih] 
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GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  causal  analysis 
and  resolution  process,  developing  the  work  products,  and 
providing  the  services  of  the  process,  [gpiosj 


Elaboration: 


Examples  of  resources  provided  include  the  following  tools:  [pais5.elio2] 

•  Database  systems 

•  Process  modeling  tools 

•  Statistical  analysis  packages 

•  Tools,  methods,  and  analysis  techniques  (e.g.,  Ishakawa  or  fishbone  diagram, 
Pareto  analysis,  histograms,  process  capability  studies,  control  charts) 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
causal  analysis  and  resolution  process,  [gpiosi 


GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  causal  analysis  and 
resolution  process  as  needed.  [gpio7] 


Elaboration: 


Examples  of  training  topics  include  the  following:  [pais5.elio3] 

•  Quality  management  methods  (e.g.,  root  cause  analysis) 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  causal  analysis  and 
resolution  process  under  appropriate  levels  of  configuration 
management,  [gpiosi 
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Elaboration: 

Examples  of  work  products  placed  under  configuration  management  include  the 
following:  [pais5.elio4] 

•  Action  proposals 

•  Action  proposals  selected  for  implementation 

•  Causal  analysis  and  resolution  records 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  of  the  causal 
analysis  and  resolution  process  as  planned.  [gpi24] 

Elaboration: 

Examples  of  activities  for  stakeholder  involvement  include  the  following:  [paiss.elho] 

•  Conducting  causal  analysis 

•  Assessing  the  action  proposals 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  causal  analysis  and  resolution  process 
against  the  plan  for  performing  the  process  and  take  appropriate 
corrective  action,  [gpho] 


Elaboration: 


Examples  of  measures  used  in  monitoring  and  controlling  include  the  following: 

[PA155.EL105] 

•  Number  of  root  causes  removed 

•  Change  in  quality  or  process  performance  per  instance  of  the  causal  analysis  and 
resolution  process 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  causal  analysis  and 
resolution  process  against  its  process  description,  standards,  and 
procedures,  and  address  noncompliance,  [gphsj 
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Elaboration: 


Examples  of  activities  reviewed  include  the  following:  [pai55.eho6] 

•  Determining  causes  of  defects 

•  Addressing  causes  of  defects 

Examples  of  work  products  reviewed  include  the  following:  [paiss.elios] 

•  Action  proposals  selected  for  implementation 

•  Causal  analysis  and  resolution  records 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  causal  analysis  and 
resolution  process  with  higher  level  management  and  resolve 
issues,  [gpii 2] 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 

GP  3.1 

Establish  a  Defined  Process 

GP  3.2 

Establish  and  maintain  the  description  of  a  defined  causal  analysis 
and  resolution  process,  igpiui 

Collect  Improvement  Information 

GG  4  Institution 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  causal  analysis  and  resolution  process  to  support  the  future 
use  and  improvement  of  the  organization’s  processes  and  process 
assets,  [g pi  i7] 

alize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 
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GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  causal 
analysis  and  resolution  process  that  address  quality  and  process 
performance  based  on  customer  needs  and  business  objectives. 

[GPU  8] 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  causal  analysis  and  resolution  process 
to  achieve  the  established  quantitative  quality  and  process- 
performance  objectives,  igpiwj 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  causal  analysis  and 
resolution  process  in  fulfilling  the  relevant  business  objectives  of 
the  organization,  igpusj 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  causal  analysis  and  resolution  process.  [gpi2ij 
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C.  Glossary 


The  CMMI  glossary  defines  many  of  the  basic  terms  used  in  the  CMMI 
models.  Glossary  entries  are  typically  multiple-word  terms  consisting  of 
a  noun  and  one  or  more  restrictive  modifiers  (e.g.,  instead  of  defining 
“tailoring,”  the  following  are  defined:  “CMMI  model  tailoring,”  “CMMI 
appraisal  tailoring,”  and  “tailoring  guidelines”).  (There  are  some 
exceptions  to  this  rule  that  account  for  one-word  terms  in  the  glossary.) 

[FM1 13.T101] 


The  glossary  was  developed  using  defined  criteria  for  the  selection  of 
terms  and  definitions.  Some  terms  were  not  included  in  the  glossary 
because  they  were  used  in  only  one  process  area  or  because  the  term 
was  used  in  an  everyday  sense.  In  either  case,  the  use  of  the  term  is 
explained  in  the  process  area.  [FM113.T102] 

To  be  considered  for  inclusion  in  the  glossary  of  CMMI  models,  terms 
must  meet  all  of  the  following  conditions:  [fmh3.tio3] 

Condition  1  -  The  entry  must  appear  in  the  CMMI  models.  The  glossary 
does  not  include  words  that  are  self  explanatory  in  the  context  of  the 
CMMI  product  or  that,  through  popular  use,  already  are  widely 
understood  by  model  users.  Terms  only  used  as  examples  and  which 
were  not  concepts  critical  to  the  use  of  CMMI  models  were  also 
excluded.  However,  if  there  was  any  doubt  as  to  how  widely  understood 
a  term  was,  the  term  was  included  in  the  glossary.  [fmh3.tio4] 

Condition  2  -  The  definition  of  the  term  is  not  satisfied  by  common 
dictionary  definition(s).  The  best  reference  source  for  term  definitions  is 
a  standard  English  dictionary.  Therefore,  once  a  term  was  identified  in 
the  CMMI  Product  Suite,  it  (or  its  component  words)  was  searched  for 
in  Miriam-Webster’s  Online  Collegiate  Dictionary  (http://www.m-w.com). 
If  the  definition  found  there  accurately  characterized  how  the  term  was 
being  used  in  CMMI  products,  the  term  was  left  out  of  the  glossary 
because  there  was  no  compelling  need  to  replicate  common  definitions 
found  in  the  Webster’s  dictionary.  [fmh3.tios] 

Condition  3  -  In  some  instances,  terms  used  in  the  CMMI  models  are 
unique  to  the  CMMI  context.  In  these  instances,  original  definitions  not 
found  in  other  contexts  were  created.  When  selecting  or  creating  CMMI 
definitions,  great  care  was  taken  to  ensure  that  the  definitions  did  not 
have  any  of  the  following  characteristics:  [fmh3.tio6] 
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•  Circular  definitions 

•  Self-defining  definitions  wherein  a  term  is  used  to  define  itself 

•  Terms  that  are  differentiated  when  they  really  are  synonyms 
according  to  the  standard  English  dictionary 

•  Overly  restrictive  definitions  that  would  hinder  use  of  the  terms 
generally  understood  by  the  public  in  more  commonplace 
situations 

•  Definitions  that  provide  explanatory  information  that  more  rightly 
belong  elsewhere  in  a  model 

When  selecting  definitions  for  terms  in  the  CMMI  glossary,  definitions 
from  recognized  sources  were  used  where  possible.  Definitions  were 
first  selected  from  existing  sources  that  have  a  widespread  readership. 

If  a  definition  was  selected  from  one  of  these  sources,  a  note  at  the  end 
of  the  definition  in  brackets  (for  example,  [ISO  9000])  was  included.  The 
order  of  precedence  used  when  selecting  definitions  was  as  follows: 

[FM1 13.T109] 

1.  Webster’s  Dictionary 

2.  ISO/IEC  9000 

3.  ISO/IEC  12207 

4.  ISO/IEC  15504 

5.  ISO/IEC  15288 

6.  CMMI  Source  Models  [fmh3.th5] 

•  IPD-CMM  v0.98 

•  EIA/IS  731  (SECM) 

•  SW-CMM  v  2,  draft  C 

7.  CMMI  A-Spec 

8.  IEEE 

9.  SW-CMM  vl.1 

10.  EIA632 

11.  SA-CMM 

12.  FAA-CMM 

13.  P-CMM  [fmi  13.T116] 

The  Glossary  was  developed  recognizing  the  importance  of  using 
terminology  that  all  model  users  can  understand.  It  is  also  recognized 
that  words  and  terms  can  have  different  meanings  in  different  contexts 
and  environments.  The  glossary  in  CMMI  models  is  designed  to 
document  the  meanings  of  words  and  terms  that  should  have  the  widest 
use  and  understanding  by  users  of  CMMI  products.  [fmh3.th7] 
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ability  to  perform 


acceptance  criteria 


acceptance  testing 


achievement  profile 


acquisition 


acquisition  strategy 


adequate 


advanced  practices 


agreement/contract 

requirements 

allocated 

requirement 


alternative  practice 


A  common  feature  of  CMMI  model  process  areas  with  a 
staged  representation  that  groups  the  generic  practices 
related  to  ensuring  that  the  project  and/or  organization  has 
the  resources  it  needs. 

The  criteria  that  a  product  or  product  component  must 
satisfy  to  be  accepted  by  a  user,  customer,  or  other 
authorized  entity. 

Formal  testing  conducted  to  enable  a  user,  customer,  or 
other  authorized  entity  to  determine  whether  to  accept  a 
product  or  product  component.  (See  “unit  testing.”) 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  the 
organization's  progress  for  each  process  area  while 
advancing  through  the  capability  levels.  (See  “target 
staging,”  “capability  level  profile,”  and  “target  profile.”) 

The  process  of  obtaining,  through  contract,  any  discrete 
action  or  proposed  action  by  the  acquisition  entity  that  would 
commit  to  invest  (appropriated  funds)  for  obtaining  products 
and  services. 

The  specific  approach  to  acquiring  products  and  services 
that  is  based  on  considerations  of  supply  sources, 
acquisition  methods,  requirements  specification  types, 
contract  or  agreement  types,  and  the  related  acquisition  risk. 

See  Chapter  3  for  an  explanation  of  how  “adequate,” 
“appropriate,”  and  “as  needed”  are  used  in  the  CMMI 
Product  Suite. 

In  the  continuous  representation,  all  the  specific  practices 
with  a  capability  level  of  two  or  higher. 

All  technical  and  nontechnical  requirements  related  to  an 
acquisition. 

Requirement  that  levies  all  or  part  of  the  performance  and 
functionality  of  a  higher  level  requirement  on  a  lower  level 
architectural  element  or  design  component. 

A  practice  that  is  a  substitute  for  one  or  more  generic  or 
specific  practices  contained  in  CMMI  models  that  achieves 
an  equivalent  effect  toward  satisfying  the  generic  or  specific 
goal  associated  with  model  practices.  Alternative  practices 
are  not  necessarily  one-for-one  replacements  for  the  generic 
or  specific  practices. 
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appraisal 
appraisal  findings 

appraisal 

participants 

appraisal  rating 


appraisal  reference 
model 

appraisal  scope 

appraisal  team 
leader 

appropriate 

as  needed 

assessment 

assignable  cause  of 
process  variation 

audit 


See  Chapter  3  for  an  explanation  of  how  “appraisal”  is  used 
in  the  CMMI  Product  Suite. 

The  conclusions  of  an  appraisal  that  identify  the  most 
important  issues,  problems,  or  opportunities  within  the 
appraisal  scope.  Findings  include,  at  a  minimum,  strengths 
and  weaknesses  based  on  valid  observations. 

Members  of  the  organizational  unit  who  participate  in 
providing  information  during  the  appraisal. 

As  used  in  CMMI  appraisal  materials,  the  value  assigned  by 
an  appraisal  team  to  either  (1)  a  CMMI  goal  or  process  area, 
(2)  the  capability  level  of  a  process  area,  or  (3)  the  maturity 
level  of  an  organizational  unit.  The  rating  is  determined  by 
enacting  the  defined  rating  process  for  the  appraisal  method 
being  employed. 

As  used  in  CMMI  appraisal  materials,  the  CMMI  model  to 
which  an  appraisal  team  correlates  implemented  process 
activities. 

The  definition  of  the  boundaries  of  the  appraisal 
encompassing  the  organizational  limits  and  the  CMMI  model 
limits. 

A  person  who  leads  the  activities  of  an  appraisal  and  has 
satisfied  the  qualification  criteria  for  experience,  knowledge, 
and  skills  defined  by  the  appraisal  method. 

See  Chapter  3  for  an  explanation  of  how  “adequate,” 
“appropriate,”  and  “as  needed”  are  used  in  the  CMMI 
Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “adequate,” 
“appropriate,”  and  “as  needed”  are  used  in  the  CMMI 
Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “assessment”  is 
used  in  the  CMMI  Product  Suite. 

In  CMMI,  the  term  “special  cause  of  process  variation”  is 
used  in  place  of  “assignable  cause  of  process  variation”  to 
ensure  consistency.  Both  terms  are  defined  identically.  (See 
“special  cause  of  process  variation.”) 

In  CMMI  process-improvement  work,  an  independent 
examination  of  a  work  product  or  set  of  work  products  to 
determine  whether  requirements  are  being  met. 
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base  measure 


base  practices 


baseline 


business  objectives 


capability 

evaluation 


capability  level 


capability  level 
profile 


capability  maturity 
model 


capable  process 


causal  analysis 


A  distinct  property  or  characteristic  of  an  entity  and  the 
method  for  quantifying  it.  (See  “derived  measures.”) 

In  the  continuous  representation,  all  the  specific  practices 
with  a  capability  level  of  1 . 

(See  “configuration  baseline,”  “process  performance 
baseline,”  and  “product  baseline.”) 

(See  “organization’s  business  objectives.”) 


An  appraisal  by  a  trained  team  of  professionals  used  as  a 
discriminator  to  select  suppliers,  for  contract  monitoring,  or 
for  incentives.  Evaluations  are  used  to  help  decision  makers 
make  better  acquisition  decisions,  improve  subcontractor 
performance,  and  provide  insight  to  a  purchasing 
organization. 

Achievement  of  process  improvement  within  an  individual 
process  area.  A  capability  level  is  defined  by  the  appropriate 
specific  and  generic  practices  for  a  process  area.  (See 
“maturity  level,”  “process  area,”  generic  practice,”  and 
“generic  goal.”) 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels.  (See  “target  staging,” 
“capability  level  profile,”  “achievement  profile,”  and  “target 
profile.”)  The  profile  may  be  an  achievement  profile  when  it 
represents  the  organization's  progress  for  each  process 
area  while  advancing  through  the  capability  levels.  Or,  the 
profile  may  be  a  target  profile  when  it  represents  an 
objective  for  process  improvement. 

A  capability  maturity  model  (CMM)  contains  the  essential 
elements  of  effective  processes  for  one  or  more  disciplines. 
It  also  describes  an  evolutionary  improvement  path  from  ad 
hoc,  immature  processes  to  disciplined,  mature  processes 
with  improved  quality  and  effectiveness. 

A  process  that  can  satisfy  its  specified  product  quality, 
service  quality,  and  process  performance  objectives.  (See 
“stable  process,”  “standard  process,”  and  “statistically 
managed  process.”) 

The  analysis  of  defects  to  determine  their  cause. 
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change 

management 


CMMI  appraisal 
tailoring 


CMMI  Framework 


CMMI  model 


CMMI  model 
component 


CMMI  model 
tailoring 


CMMI  Product  Suite 


commitment  to 
perform 


common  cause  of 
process  variation 

concept  of 
operations 

configuration  audit 


Judicious  use  of  means  to  effect  a  change,  or  proposed 
change,  on  a  product  or  service.  (See  “configuration 
management.”) 

Selection  of  options  within  the  appraisal  method  for  use  in  a 
specific  instance. 

The  intent  of  appraisal  tailoring  is  to  assist  an  organization  in 
aligning  application  of  the  method  with  its  business 
objectives. 

See  Chapter  3  for  an  explanation  of  how  “CMMI  Framework” 
is  used  in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “CMMI  model”  is 
used  in  the  CMMI  Product  Suite. 

Any  of  the  main  architectural  elements  that  compose  a 
CMMI  model.  Some  of  the  main  elements  of  a  CMMI  model 
include  specific  practices,  generic  practices,  specific  goals, 
generic  goals,  process  areas,  capability  levels,  and  maturity 
levels. 

The  use  of  a  subset  of  a  CMMI  model  for  the  purpose  of 
making  it  suitable  for  a  specific  application.  The  intent  of 
model  tailoring  is  to  assist  an  organization  in  aligning 
application  of  a  model  with  its  business  objectives. 

See  Chapter  3  for  an  explanation  of  how  “CMMI  Product 
Suite”  is  used  in  the  CMMI  Product  Suite.  (See  “CMMI 
Framework.”) 

A  common  feature  of  CMMI  model  process  areas  with  a 
staged  representation  that  groups  the  generic  practices 
related  to  creating  policies  and  securing  sponsorship. 

The  variation  of  a  process  that  exists  because  of  normal  and 
expected  interactions  among  the  components  of  a  process. 
(See  “special  cause  of  process  variation.”) 

(See  “operational  concept.”) 

An  audit  conducted  to  verify  that  a  configuration  item 
conforms  to  a  specified  standard  or  requirement.  (See 
“audit”  and  “configuration  item.”) 
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configuration 
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configuration 
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configuration  status 
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The  configuration  information  formally  designated  at  a 
specific  time  during  a  product's  or  product  component's  life. 
Configuration  baselines,  plus  approved  changes  from  those 
baselines,  constitute  the  current  configuration  information. 

(See  “product  life  cycle.”) 

An  element  of  configuration  management  consisting  of  the 
evaluation,  coordination,  approval  or  disapproval,  and 
implementation  of  changes  to  configuration  items  after 
formal  establishment  of  their  configuration  identification. 

(See  “configuration  management,”  “configuration 
identification,”  and  “configuration  item.”) 

A  group  of  people  responsible  for  evaluating  and  approving 
or  disapproving  proposed  changes  to  configuration  items, 
and  for  ensuring  implementation  of  approved  changes.  (See 
“configuration  item.”)  Configuration  control  boards  are  also 
known  as  “change  control  boards.” 

An  element  of  configuration  management  consisting  of 
selecting  the  configuration  items  for  a  product,  assigning 
unique  identifiers  to  them,  and  recording  their  functional  and 
physical  characteristics  in  technical  documentation.  (See 
“configuration  management,”  “configuration  item,”  and 
“product.”) 

An  aggregation  of  work  products  that  is  designated  for 
configuration  management  and  treated  as  a  single  entity  in 
the  configuration  management  process.  (See  “configuration 
management.”) 

A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item,  (2) 
control  changes  to  those  characteristics,  (3)  record  and 
report  change  processing  and  implementation  status,  and 
(4)  verify  compliance  with  specified  requirements.  [IEEE  Std 
610.1990]  (See  “configuration  identification,”  “configuration 
control,”  “configuration  status  accounting,”  and 
“configuration  audit.”) 

An  element  of  configuration  management  consisting  of  the 
recording  and  reporting  of  information  needed  to  manage  a 
configuration  effectively.  This  information  includes  a  listing 
of  the  approved  configuration  identification,  the  status  of 
proposed  changes  to  the  configuration,  and  the 
implementation  status  of  approved  changes.  (See 
“configuration  management”  and  “configuration 
identification.”) 
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continuous 

representation 

contractor 
corrective  action 

COTS 

customer 

data  management 
defect  density 
defined  process 

derived  measures 

derived 

requirements 

design  review 

development 


A  capability  maturity  model  structure  wherein  capability 
levels  provide  a  recommended  order  for  approaching 
process  improvement  within  each  specified  process  area. 
(See  “staged  representation,”  “capability  level,”  and  “process 
area.”) 

(See  “supplier.”) 

Acts  or  deeds  used  to  remedy  a  situation,  remove  an  error, 
or  adjust  a  condition. 

Items  that  can  be  purchased  from  a  commercial  vendor. 
(COTS  stands  for  “commercial  off  the  shelf.”) 

See  Chapter  3  for  an  explanation  of  how  “customer”  is  used 
in  the  CMMI  Product  Suite. 


Principles,  processes,  and  systems  for  the  sharing  and 
management  of  data. 

Number  of  defects  per  unit  of  product  size  (e.g.,  problem 
reports  per  1000  lines  of  code). 

See  Chapter  3  for  an  explanation  of  how  “defined  process” 
is  used  in  the  CMMI  Product  Suite. 

Data  resulting  from  the  mathematical  function  of  two  or  more 
base  measures.  (See  “base  measure.”) 

Requirements  that  are  not  explicitly  stated  in  the  customer 
requirements,  but  are  inferred  (1)  from  contextual 
requirements  (e.g.,  applicable  standards,  laws,  policies, 
common  practices,  and  management  decisions),  or  (2)  from 
requirements  needed  to  specify  a  product  component. 
Derived  requirements  can  also  arise  during  analysis  and 
design  of  components  of  the  product  or  system.  (See 
“product  requirements.”) 

A  formal,  documented,  comprehensive,  and  systematic 
examination  of  a  design  to  evaluate  the  design  requirements 
and  the  capability  of  the  design  to  meet  these  requirements, 
and  to  identify  problems  and  propose  solutions. 

See  Chapter  3  for  an  explanation  of  how  “development”  is 
used  in  the  CMMI  Product  Suite. 
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developmental  plan 

directing 

implementation 

discipline 

amplification 

enterprise 
entry  criteria 
equivalent  staging 


establish  and 
maintain 

evidence 

executive 

exit  criteria 

expected  CMMI 
components 


A  plan  for  guiding,  implementing,  and  controlling  the  design 
and  development  of  one  or  more  products.  (See  “project 
plan”  and  “product  life  cycle.”) 

A  common  feature  of  CMMI  model  process  areas  with  a 
staged  representation  that  groups  the  generic  practices 
related  to  managing  the  performance  of  the  process, 
managing  the  integrity  of  its  work  products,  and  involving 
relevant  stakeholders. 

See  Chapter  2  for  an  explanation  of  how  “discipline 
amplification”  is  used  in  the  CMMI  Product  Suite. 


See  Chapter  3  for  an  explanation  of  how  “enterprise”  is  used 
in  the  CMMI  Product  Suite. 

States  of  being  that  must  be  present  before  an  effort  can 
begin  successfully. 

Equivalent  staging  is  a  target  staging,  created  using  the 
continuous  representation  that  is  defined  so  that  the  results 
of  using  the  target  staging  can  be  compared  to  the  maturity 
levels  of  the  staged  representation.  (See  “target  staging,” 
“maturity  level,”  “capability  level  profile,”  and  “target  profile.”) 

Such  staging  permits  benchmarking  of  progress  among 
organizations,  enterprises,  and  projects,  regardless  of  the 
CMMI  representation  used.  The  organization  may 
implement  components  of  CMMI  models  beyond  those 
reported  as  part  of  equivalent  staging.  Equivalent  staging  is 
only  a  measure  to  relate  how  the  organization  is  compared 
to  other  organizations  in  terms  of  maturity  levels. 

See  Chapter  3  for  an  explanation  of  how  “establish  and 
maintain”  is  used  in  the  CMMI  Product  Suite. 

(See  “objective  evidence.”) 

(See  “senior  manager.”) 

States  of  being  that  must  be  present  before  an  effort  can 
end  successfully. 

CMMI  components  that  explain  what  may  be  done  to  satisfy 
a  required  CMMI  component.  Model  users  can  implement 
the  expected  components  explicitly  or  implement  equivalent 
alternative  practices  to  these  components.  Specific  and 
generic  practices  are  expected  model  components. 
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finding 

formal  evaluation 
process 

framework 
functional  analysis 


functional 

architecture 

generic  goal 

generic  practice 

generic  practice 
elaboration 

goal 

incomplete  process 

independent  group 


(See  “appraisal  findings.”) 

In  the  Decision  Analysis  and  Resolution  process  area,  see 
the  definition  of  a  “formal  evaluation  process”  in  the 
introductory  notes. 

(See  “CMMI  Framework.”) 

Examination  of  a  defined  function  to  identify  all  the 
subfunctions  necessary  to  the  accomplishment  of  that 
function;  identification  of  functional  relationships  and 
interfaces  (internal  and  external)  and  capturing  these  in  a 
functional  architecture;  and  flow  down  of  upper  level 
performance  requirements  and  assignment  of  these 
requirements  to  lower  level  subfunctions.  (See  “functional 
architecture.”) 

The  hierarchical  arrangement  of  functions,  their  internal  and 
external  (external  to  the  aggregation  itself)  functional 
interfaces  and  external  physical  interfaces,  their  respective 
functional  and  performance  requirements,  and  their  design 
constraints. 


See  Chapter  2  for  an  explanation  of  how  “generic  goal”  is 
used  in  the  CMMI  Product  Suite. 

See  Chapter  2  for  an  explanation  of  how  “generic  practice” 
is  used  in  the  CMMI  Product  Suite. 

See  Chapter  2  for  an  explanation  of  how  “generic  practice 
elaboration”  is  used  in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “goal”  is  used  in 
the  CMMI  Product  Suite. 


A  process  that  is  not  performed  or  is  only  performed  partially 
(also  known  as  capability  level  0).  One  or  more  of  the 
specific  goals  of  the  process  area  are  not  satisfied. 

In  the  Process  and  Product  Quality  Assurance  process  area, 
see  the  discussion  of  a  “group  that  is  independent”  in  the 
introductory  notes. 
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informative  CMMI 
components 


institutionalization 

Integrated  Product 
and  Process 
Development 


integrated  team 


interface  control 


lead  appraiser 


life-cycle  model 


managed  process 


CMMI  components  that  help  model  users  understand  the 
required  and  expected  components  of  a  model.  These 
components  may  contain  examples,  detailed  explanations, 
or  other  helpful  information.  Subpractices,  notes,  references, 
goal  titles,  practice  titles,  sources,  typical  work  products, 
discipline  amplifications,  and  generic  practice  elaborations 
are  informative  model  components. 

The  ingrained  way  of  doing  business  that  an  organization 
follows  routinely  as  part  of  its  corporate  culture. 

A  systematic  approach  to  product  development  that 
achieves  a  timely  collaboration  of  relevant  stakeholders 
throughout  the  product  life  cycle  to  better  satisfy  customer 
needs. 

A  group  of  people  with  complementary  skills  and  expertise 
who  are  committed  to  delivering  specified  work  products  in 
timely  collaboration.  Integrated  team  members  provide  skills 
and  advocacy  appropriate  to  all  phases  of  the  work 
products’  life  and  are  collectively  responsible  for  delivering 
the  work  products  as  specified.  An  integrated  team  should 
include  empowered  representatives  from  organizations, 
disciplines,  and  functions  that  have  a  stake  in  the  success  of 
the  work  products. 

In  configuration  management,  the  process  of  (1)  identifying 
all  functional  and  physical  characteristics  relevant  to  the 
interfacing  of  two  or  more  configuration  items  provided  by 
one  or  more  organizations,  and  (2)  ensuring  that  the 
proposed  changes  to  these  characteristics  are  evaluated 
and  approved  prior  to  implementation.  [IEEE  828-1983] 

(See  “configuration  management”  and  “configuration  item.”) 


As  used  in  the  CMMI  Product  Suite,  a  person  who  has 
achieved  recognition  from  an  authorizing  body  to  perform  as 
an  appraisal  team  leader  for  a  particular  appraisal  method. 

A  partitioning  of  the  life  of  a  product  into  phases  that  guide 
the  project  from  identifying  customer  needs  through  product 
retirement. 


See  Chapter  3  for  an  explanation  of  how  “managed  process” 
is  used  in  the  CMMI  Product  Suite. 
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maturity  level 

memorandum  of 
agreement 

natural  bounds 


non-developmental 

item 


nontechnical 

requirements 


objective 


objective  evidence 


See  Chapter  3  for  an  explanation  of  how  “manager”  is  used 
in  the  CMMI  Product  Suite. 

Degree  of  process  improvement  across  a  predefined  set  of 
process  areas  in  which  all  goals  within  the  set  are  attained. 
(See  “capability  level”  and  “process  area.”) 

Binding  documents  of  understanding  or  agreements 
between  two  or  more  parties.  (Also  known  as  a 
“memorandum  of  understanding.”) 


The  inherent  process  reflected  by  measures  of  process 
performance,  sometimes  referred  to  as  “voice  of  the 
process.”  Techniques  such  as  control  charts,  confidence 
intervals,  and  prediction  intervals  are  used  to  determine 
whether  the  variation  is  due  to  common  causes  (i.e.,  the 
process  is  predictable  or  “stable”)  or  is  due  to  some  special 
cause  that  can  and  should  be  identified  and  removed. 

An  item  of  supply  that  was  developed  previous  to  its  current 
use  in  an  acquisition  or  development  process.  Such  an  item 
may  require  minor  modifications  to  meet  the  requirements  of 
its  current  intended  use. 

Contractual  provisions,  commitments,  conditions,  and  terms 
that  affect  how  products  or  services  are  to  be  acquired. 
Examples  include  products  to  be  delivered,  data  rights  for 
delivered  commercial  off-the-shelf  (COTS)  non- 
developmental  items  (NDIs),  delivery  dates,  and  milestones 
with  exit  criteria.  Other  nontechnical  requirements  include 
training  requirements,  site  requirements,  and  deployment 
schedules. 


See  Chapter  3  for  an  explanation  of  how  “objective”  is  used 
in  the  CMMI  Product  Suite. 

As  used  in  CMMI  appraisal  materials,  qualitative  or 
quantitative  information,  records,  or  statements  of  fact 
pertaining  to  the  characteristics  of  an  item  or  service  or  to 
the  existence  and  implementation  of  a  process  element, 
which  are  based  on  observation,  measurement,  or  test  and 
which  are  verifiable. 
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To  review  activities  and  work  products  against  criteria  that 
minimize  subjectivity  and  bias  by  the  reviewer.  An  example 
of  an  objective  evaluation  is  an  audit  against  requirements, 
standards,  or  procedures  by  an  independent  quality 
assurance  function.  (See  “audit.”) 

As  used  in  CMMI  appraisal  materials,  a  written  record  that 
represents  the  appraisal  team  members’  understanding  of 
information  either  seen  or  heard  during  the  appraisal  data 
collection  activities.  The  written  record  may  take  the  form  of 
a  statement  or  may  take  alternative  forms  as  long  as  the 
information  content  is  preserved. 

A  general  description  of  the  way  in  which  an  entity  is  used  or 
operates.  (Also  known  as  “concept  of  operations.”) 

A  description  of  an  imagined  sequence  of  events  that 
includes  the  interaction  of  the  product  with  its  environment 
and  users,  as  well  as  interaction  among  its  product 
components.  Operational  scenarios  are  used  to  evaluate  the 
requirements  and  design  of  the  system  and  to  verify  and 
validate  the  system. 

A  quantitatively  managed  process  that  is  improved  based  on 
an  understanding  of  the  common  causes  of  variation 
inherent  in  the  process.  A  process  that  focuses  on 
continually  improving  the  range  of  process  performance 
through  both  incremental  and  innovative  improvements. 

(See  “quantitatively  managed  process,”  “defined  process,” 
and  “common  cause  of  process  variation.”) 

See  Chapter  3  for  an  explanation  of  how  “organization”  is 
used  in  the  CMMI  Product  Suite. 

Senior-management-developed  strategies  designed  to 
ensure  an  organization's  continued  existence  and  enhance 
its  profitability,  market  share,  and  other  factors  influencing 
the  organization’s  success.  (See  “quantitative  objective”  and 
“quality  and  process-performance  objectives.”) 

Such  objectives  may  include  reducing  the  number  of  change 
requests  during  a  system's  integration  phase,  reducing 
development  cycle  time,  increasing  the  number  of  errors 
found  in  a  product’s  first  or  second  phase  of  development, 
reducing  the  number  of  customer-reported  defects,  etc., 
when  applied  to  systems-engineering  activities. 

See  Chapter  3  for  an  explanation  of  how  “organization’s 
measurement  repository”  is  used  in  the  CMMI  Product  Suite. 
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See  Chapter  3  for  an  explanation  of  how  “organization’s 
process  asset  library”  is  used  in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “organization’s  set 
of  standard  processes”  is  used  in  the  CMMI  Product  Suite. 
(See  “defined  process”  and  “process  element.”) 

The  extent  to  which  an  organization  has  explicitly  and 
consistently  deployed  processes  that  are  documented, 
managed,  measured,  controlled,  and  continually  improved. 
Organizational  maturity  may  be  measured  via  appraisals. 

A  guiding  principle  typically  established  by  senior 
management  that  is  adopted  by  an  organization  to  influence 
and  determine  decisions. 

See  Chapter  3  for  an  explanation  of  how  “organizational 
process  assets”  is  used  in  the  CMMI  Product  Suite. 

That  part  of  an  organization  that  is  the  subject  of  an 
appraisal  (also  known  as  the  organizational  scope  of  the 
appraisal). 

An  organizational  unit  deploys  one  or  more  processes  that 
have  a  coherent  process  context  and  operates  within  a 
coherent  set  of  business  objectives.  An  organizational  unit  is 
typically  part  of  a  larger  organization,  although  in  a  small 
organization,  the  organizational  unit  may  be  the  whole 
organization. 

(See  “acquisition.”) 


See  Chapter  3  for  an  explanation  of  how  “peer  review”  is 
used  in  the  CMMI  Product  Suite. 

The  measures  of  effectiveness  and  other  key  measures 
used  to  guide  and  control  progressive  development. 

A  process  that  accomplishes  the  needed  work  to  produce 
identified  output  work  products  using  identified  input  work 
products  (also  known  as  capability  level  1).  The  specific 
goals  of  the  process  area  are  satisfied. 

A  process  that  is  documented  both  by  a  description  and  a 
plan.  The  description  and  plan  should  be  coordinated,  and 
the  plan  should  include  standards,  requirements,  objectives, 
resources,  assignments,  etc. 
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(See  “organizational  policy.”) 

See  Chapter  3  for  an  explanation  of  how  “process”  is  used 
in  the  CMMI  Product  Suite. 

In  the  Organizational  Process  Focus  process  area,  see  the 
definition  of  “process  action  plan”  in  the  introductory  notes. 

A  team  that  has  the  responsibility  to  develop  and  implement 
process-improvement  activities  for  an  organization  as 
documented  in  the  process-improvement  action  plan. 

In  the  Organizational  Innovation  and  Deployment  process 
area,  see  the  discussion  of  “process  and  technology 
improvements”  in  the  introductory  notes. 

See  Chapter  3  for  an  explanation  of  how  “process 
architectures”  is  used  in  the  CMMI  Product  Suite. 

See  Chapter  2  for  an  explanation  of  how  “process  area”  is 
used  in  the  CMMI  Product  Suite. 

Anything  that  the  organization  considers  useful  in  attaining 
the  goals  of  a  process  area.  (See  “organizational  process 
assets.”) 

A  collection  of  process  asset  holdings  that  can  be  used  by 
an  organization  or  project.  (See  “organization’s  process 
asset  library.”) 

A  measurable  characteristic  of  process  capability  applicable 
to  any  process. 

The  range  of  expected  results  that  can  be  achieved  by 
following  a  process.  [EIA/IS  731,  VI. 0] 

The  set  of  factors,  documented  in  the  appraisal  input,  that 
influences  the  judgment  and  comparability  of  appraisal 
ratings. 

These  include,  but  are  not  limited  to,  the  size  of  the 
organizational  unit  to  be  appraised;  the  demographics  of  the 
organizational  unit;  the  application  discipline  of  the  products 
or  services;  the  size,  criticality,  and  complexity  of  the 
products  or  services;  and  the  quality  characteristics  of  the 
products  or  services. 
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The  act  of  defining  and  describing  a  process.  The  result  of 
process  definition  is  a  process  description.  (See  “process 
description.”) 

A  documented  expression  of  a  set  of  activities  performed  to 
achieve  a  given  purpose  that  provides  an  operational 
definition  of  the  major  components  of  a  process.  The 
documentation  specifies,  in  a  complete,  precise,  and 
verifiable  manner,  the  requirements,  design,  behavior,  or 
other  characteristics  of  a  process.  It  also  may  include 
procedures  for  determining  whether  these  provisions  have 
been  satisfied.  Process  descriptions  may  be  found  at  the 
activity,  project,  or  organizational  level. 

The  fundamental  unit  of  a  process.  A  process  may  be 
defined  in  terms  of  subprocesses  or  process  elements.  A 
subprocess  can  be  further  decomposed;  a  process  element 
cannot. 

Each  process  element  covers  a  closely  related  set  of 
activities  (for  example,  estimating  element,  peer  review 
element).  Process  elements  can  be  portrayed  using 
templates  to  be  completed,  abstractions  to  be  refined,  or 
descriptions  to  be  modified  or  used.  A  process  element  can 
be  an  activity  or  task. 

A  collection  of  specialists  that  facilitate  the  definition, 
maintenance,  and  improvement  of  the  process(es)  used  by 
the  organization. 

A  program  of  activities  designed  to  improve  the  performance 
and  maturity  of  the  organization's  processes,  and  the  results 
of  such  a  program. 

A  set  of  target  characteristics  established  to  guide  the  effort 
to  improve  an  existing  process  in  a  specific  measurable  way 
either  in  terms  of  resultant  product  characteristics  (e.g., 
quality,  performance,  conformance  to  standards,  etc.)  or  in 
the  way  in  which  the  process  is  executed  (e.g.,  elimination 
of  redundant  process  steps,  combining  process  steps, 
improving  cycle  time,  etc.).  (See  “quantitative  objective”  and 
“organization's  business  objectives.”) 

In  the  Organizational  Process  Focus  process  area,  see  the 
definition  of  “process-improvement  plan”  in  the  introductory 
notes. 
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The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for 
the  purpose  of  characterizing  and  understanding  the 
process. 

The  person  (or  team)  responsible  for  defining  and 
maintaining  a  process.  At  the  organizational  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  a  standard  process;  at  the  project  level,  the 
process  owner  is  the  person  (or  team)  responsible  for  the 
description  of  the  defined  process.  A  process  may  therefore 
have  multiple  owners  at  different  levels  of  responsibility. 

(See  “standard  process”  and  “defined  process.”) 

A  measure  of  actual  results  achieved  by  following  a  process. 
It  is  characterized  by  both  process  measures  (e.g.,  effort, 
cycle  time,  and  defect  removal  efficiency)  and  product 
measures  (e.g.,  reliability,  defect  density,  and  response 
time). 

A  documented  characterization  of  the  actual  results 
achieved  by  following  a  process,  which  is  used  as  a 
benchmark  for  comparing  actual  process  performance 
against  expected  process  performance.  (See  “process 
performance.”) 

A  description  of  the  relationships  among  attributes  of  a 
process  and  its  work  products  that  are  developed  from 
historical  process  performance  data  and  calibrated  using 
collected  process  and  product  measures  from  the  project 
and  which  are  used  to  predict  results  to  be  achieved  by 
following  a  process. 

To  make,  alter,  or  adapt  a  process  description  for  a 
particular  end.  For  example,  a  project  tailors  its  defined 
process  from  the  organization's  set  of  standard  processes  to 
meet  the  objectives,  constraints,  and  environment  of  the 
project.  (See  “process  description,”  “organization's  set  of 
standard  processes,”  and  “defined  process.”) 

See  Chapter  3  for  an  explanation  of  how  “product”  is  used  in 
the  CMMI  Product  Suite. 

In  configuration  management,  the  initial  approved  technical 
data  package  (including,  for  software,  the  source  code 
listing)  defining  a  configuration  item  during  the  production, 
operation,  maintenance,  and  logistic  support  of  its  life  cycle. 
(See  “configuration  management”  and  “configuration  item.”) 


Glossary 


557 


CMMI-SW,  vl.1 
Continuous  Representation 


product  component 

product-component 

requirements 

product  life  cycle 

product  line 

product-related  life- 
cycle  processes 

product 

requirements 

product  suite 

profile 

program 

project 

project  manager 

project  plan 

project  progress 
and  performance 


See  Chapter  3  for  an  explanation  of  how  “product 
component”  is  used  in  the  CMMI  Product  Suite. 

Product-component  requirements  provide  a  complete 
specification  of  a  product  component,  including  fit,  form, 
function,  performance,  and  any  other  requirement. 

See  Chapter  3  for  an  explanation  of  how  “product  life  cycle” 
is  used  in  the  CMMI  Product  Suite. 

A  group  of  products  sharing  a  common,  managed  set  of 
features  that  satisfy  specific  needs  of  a  selected  market  or 
mission. 

Processes  associated  with  a  product  throughout  one  or 
more  phases  of  its  life  (i.e. ,  from  conception  through 
disposal),  such  as  the  manufacturing  and  support 
processes. 

A  refinement  of  the  customer  requirements  into  the 
developers'  language,  making  implicit  requirements  into 
explicit  derived  requirements.  (See  “product-component 
requirements”  and  “derived  requirements.”)  The  developer 
uses  the  product  requirements  to  guide  the  design  and 
building  of  the  product. 

(See  “CMMI  Product  Suite.”) 

(See  “achievement  profile”  and  “target  profile.”) 

(1 )  A  project.  (2)  A  collection  of  related  projects  and  the 
infrastructure  that  supports  them,  including  objectives, 
methods,  activities,  plans,  and  success  measures.  (See 
“project.”) 

See  Chapter  3  for  an  explanation  of  how  “project”  is  used  in 
the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “project  manager” 
is  used  in  the  CMMI  Product  Suite. 

In  the  Project  Planning  process  area,  see  the  definition  of 
“project  plan”  in  the  introductory  notes. 

What  a  project  achieves  with  respect  to  implementing 
project  plans,  including  effort,  cost,  schedule,  and  technical 
performance. 
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In  the  Integrated  Project  Management  process  area,  see  the 
definition  of  “project’s  defined  process”  in  the  introductory 
notes  and  in  the  Establish  the  Project's  Defined  Process 
specific  practice. 

A  preliminary  type,  form,  or  instance  of  a  product  or  product 
component  that  serves  as  a  model  for  later  stages  or  for  the 
final,  complete  version  of  the  product.  This  model  (physical, 
electronic,  digital,  analytical,  etc.)  can  be  used  for  the 
following  (and  other)  purposes: 

•  assessing  the  feasibility  of  a  new  or  unfamiliar 
technology 

•  assessing  or  mitigating  technical  risk 

•  validating  requirements 

•  demonstrating  critical  features 

•  qualifying  a  product 

•  qualifying  a  process 

•  characterizing  performance  or  product  features 

•  elucidating  physical  principles 


The  ability  of  a  set  of  inherent  characteristics  of  a  product, 
product  component,  or  process  to  fulfill  requirements  of 
customers. 

See  Chapter  3  for  an  explanation  of  how  “quality  and 
process-performance  objectives”  is  used  in  the  CMMI 
Product  Suite. 

A  planned  and  systematic  means  for  assuring  management 
that  defined  standards,  practices,  procedures,  and  methods 
of  the  process  are  applied. 

The  operational  techniques  and  activities  that  are  used  to 
fulfill  requirements  for  quality.  [ISO  8402-1994]  (See  “quality 
assurance.”) 

Desired  target  value  expressed  as  quantitative  measures. 
(See  “quality  and  process-performance  objectives”  and 
“process-improvement  objectives.”) 
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A  defined  process  that  is  controlled  using  statistical  and 
other  quantitative  techniques.  The  product  quality,  service 
quality,  and  process  performance  attributes  are  measurable 
and  controlled  throughout  the  project.  (See  “optimizing 
process,”  “defined  process,”  and  “statistically  managed 
process.”) 


(See  “appraisal  rating.”) 

See  Chapter  2  for  an  explanation  of  how  “reference”  is  used 
in  the  CMMI  Product  Suite. 

A  model  that  is  used  as  a  benchmark  for  measuring  some 
attribute. 

See  Chapter  3  for  an  explanation  of  how  “relevant 
stakeholder”  is  used  in  the  CMMI  Product  Suite. 

In  Chapter  1,  see  the  definitions  of  “staged  representation” 
and  “continuous  representation.” 

CMMI  components  that  are  essential  to  achieving  process 
improvement  in  a  given  process  area.  These  components 
are  used  in  appraisals  to  determine  process  capability. 
Specific  goals  and  generic  goals  are  required  model 
components. 

(1 )  A  condition  or  capability  needed  by  a  user  to  solve  a 
problem  or  achieve  an  objective.  (2)  A  condition  or  capability 
that  must  be  met  or  possessed  by  a  product  or  product 
component  to  satisfy  a  contract,  standard,  specification,  or 
other  formally  imposed  documents.  (3)  A  documented 
representation  of  a  condition  or  capability  as  in  (1 )  or  (2). 
[IEEE  610.12-1990] 

The  determination  of  product-specific  performance  and 
functional  characteristics  based  on  analyses  of  customer 
needs,  expectations,  and  constraints;  operational  concept; 
projected  utilization  environments  for  people,  products,  and 
processes;  and  measures  of  effectiveness. 

Using  systematic  techniques,  like  prototypes  and  structured 
surveys,  to  proactively  identify  and  document  customer  and 
end-user  needs. 
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The  management  of  all  requirements  received  by  or 
generated  by  the  project,  including  both  technical  and 
nontechnical  requirements  as  well  as  those  requirements 
levied  on  the  project  by  the  organization. 

The  evidence  of  an  association  between  a  requirement  and 
its  source  requirement,  its  implementation,  and  its 
verification. 

The  ratio  of  revenue  from  output  (product)  to  production 
costs,  which  determines  whether  an  organization  benefits 
from  performing  an  action  to  produce  something. 

The  evaluation,  classification,  and  prioritization  of  risks. 

An  organized,  thorough  approach  to  seek  out  probable  or 
realistic  risks  in  achieving  objectives. 

An  organized,  analytic  process  to  identify  what  might  cause 
harm  or  loss  (identify  risks),  assess  and  quantify  the 
identified  risks,  and  to  develop  and,  if  needed,  implement  an 
appropriate  approach  to  prevent  or  handle  risk  causes  that 
could  result  in  significant  harm  or  loss. 

An  organized,  technical  approach  to  identify  what  might 
cause  harm  or  loss  (identify  risks),  assess  and  quantify  the 
identified  risks,  and  to  develop  and  if  needed  implement  an 
appropriate  approach  to  prevent  or  handle  risk  causes  that 
could  result  in  significant  harm  or  loss.  Typically,  risk 
management  is  performed  for  project,  organization,  or 
product-developing  organizational  units. 

A  root  cause  is  a  source  of  a  defect  such  that  if  it  is 
removed,  the  defect  is  decreased  or  removed. 


See  Chapter  3  for  an  explanation  of  how  “senior  manager”  is 
used  in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “shared  vision”  is 
used  in  the  CMMI  Product  Suite. 

(1)The  application  of  a  systematic,  disciplined,  quantifiable 
approach  to  the  development,  operation,  and  maintenance 
of  software.  (2)  The  study  of  approaches  as  in  (1). 

The  process  of  preparing  a  solicitation  package  and 
selecting  a  supplier  (contractor). 
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A  formal  document  delineating  technical  and  nontechnical 
requirements  that  is  used  to  request  offers  on  invitations  for 
bids  (bids)  and  requests  for  proposal  (proposals),  or  to 
request  statements  of  capabilities  and  price  quotations 
(quotes).  It  is  otherwise  used  as  a  basis  for  selecting  a 
supply  source  or  sources  to  provide  products  or  services. 

A  cause  of  a  defect  that  is  specific  to  some  transient 
circumstance  and  not  an  inherent  part  of  a  process.  (See 
“common  cause  of  process  variation.”) 

See  Chapter  2  for  an  explanation  of  how  “specific  goal”  is 
used  in  the  CMMI  Product  Suite.  (See  “process  area,” 
“capability  level,”  “generic  goal,”  “quantitative  objective,”  and 
“organization's  business  objectives.”) 

See  Chapter  2  for  an  explanation  of  how  “specific  practice” 
is  used  in  the  CMMI  Product  Suite.  (See  “process  area”  and 
“specific  goal.”) 

The  state  in  which  all  special  causes  of  process  variation 
have  been  removed  and  prevented  from  recurring  so  that 
only  the  common  causes  of  process  variation  of  the  process 
remain.  (See  “special  cause  of  process  variation,”  “common 
cause  of  variation,”  “standard  process,”  “statistically 
managed  process,”  and  “capable  process.”) 

A  model  structure  wherein  attaining  the  goals  of  a  set  of 
process  areas  establishes  a  maturity  level;  each  level  builds 
a  foundation  for  subsequent  levels.  (See  “process  area”  and 
“maturity  level.”) 

See  Chapter  3  for  an  explanation  of  how  “stakeholder”  is 
used  in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “standard”  is  used 
in  the  CMMI  Product  Suite. 

An  operational  definition  of  the  basic  process  that  guides  the 
establishment  of  a  common  process  in  an  organization. 
[ISO/I  EC  15504-9] 

A  standard  process  describes  the  fundamental  process 
elements  that  are  expected  to  be  incorporated  into  any 
defined  process.  It  also  describes  the  relationships  (e.g., 
ordering  and  interfaces)  between  these  process  elements. 
(See  Chapter  3  for  an  explanation  of  how  “defined  process” 
is  used  in  the  CMMI  Product  Suite.) 
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statement  of  work 

statistical 

predictability 

statistical  process 
control 

statistical 

techniques 

statistically 
managed  process 

strength 

subpractice 

subprocess 

supplier 

sustainment 


A  description  of  contracted  work  required  to  complete  a 
project. 

The  performance  of  a  quantitative  process  that  is  controlled 
using  statistical  and  other  quantitative  techniques. 

Statistically  based  analysis  of  a  process  and  measurements 
of  process  performance,  which  will  identify  common  and 
special  causes  of  variation  in  the  process  performance,  and 
maintain  process  performance  within  limits.  (See  “common 
cause  of  process  variation,”  “statistically  managed  process,” 
and  “special  cause  of  process  variation.”) 

An  analytic  technique  that  employs  statistical  methods  (e.g., 
statistical  process  control,  confidence  intervals,  prediction 
intervals). 

A  process  that  is  managed  by  a  statistically  based  technique 
in  which  processes  are  analyzed,  special  causes  of  process 
variation  are  identified,  and  performance  is  contained  within 
well-defined  limits.  (See  “stable  process,”  “standard 
process,”  “statistical  process  control,”  “capable  process,” 
and  “special  cause  of  process  variation.”) 

As  used  in  CMMI  appraisal  materials,  an  exemplary  or 
noteworthy  implementation  of  a  CMMI  model  practice. 

See  Chapter  2  for  an  explanation  of  how  “subpractice”  is 
used  in  the  CMMI  Product  Suite. 

A  process  that  is  part  of  a  larger  process.  (See  “process 
description.”) 

(1 )  An  entity  delivering  products  or  performing  services 
being  acquired.  (2)  An  individual,  partnership,  company, 
corporation,  association,  or  other  service  having  an 
agreement  (contract)  with  an  acquirer  for  the  design, 
development,  manufacture,  maintenance,  modification,  or 
supply  of  items  under  the  terms  of  an  agreement  (contract). 

The  processes  used  to  ensure  that  a  product  can  be  utilized 
operationally  by  its  end  users  or  customers.  Sustainment 
ensures  that  maintenance  is  done  such  that  the  product  is  in 
an  operable  condition  whether  the  product  is  in  use  or  not  by 
customers  or  end  users. 
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systems 

engineering 


tailoring  guidelines 
target  profile 

target  staging 

technical  data 
package 


The  interdisciplinary  approach  governing  the  total  technical 
and  managerial  effort  required  to  transform  a  set  of 
customer  needs,  expectations,  and  constraints  into  a 
product  solution  and  support  that  solution  throughout  the 
product’s  life. 

This  includes  the  definition  of  technical  performance 
measures,  the  integration  of  engineering  specialties  towards 
the  establishment  of  a  product  architecture,  and  the 
definition  of  supporting  life-cycle  processes  that  balance 
cost,  performance,  and  schedule  objectives. 


See  Chapter  3  for  an  explanation  of  how  “tailoring 
guidelines”  is  used  in  the  CMMI  Product  Suite. 

In  the  continuous  representation,  a  list  of  process  areas  and 
their  corresponding  capability  levels  that  represent  an 
objective  for  process  improvement.  (See  “capability  level 
profile”  and  “achievement  profile.”) 

In  the  continuous  representation,  a  sequence  of  target 
profiles  that  describes  the  path  of  process  improvement  to 
be  followed  by  the  organization.  (See  “capability  level 
profile,”  “achievement  profile,”  and  “target  profile.”) 

A  collection  of  items  that  may  include  the  following  if  such 
information  is  appropriate  to  the  type  of  product  and  product 
component  (for  example,  material  and  manufacturing 
requirements  may  not  be  useful  for  product  components 
associated  with  software  services  or  processes): 

•  product  architecture  description 

•  allocated  requirements 

•  product-component  descriptions 

•  product-related  life-cycle  process  descriptions  if  not 
described  as  separate  product  components 

•  key  product  characteristics 

•  required  physical  characteristics  and  constraints 

•  interface  requirements 

•  materials  requirements  (bills  or  material  and  material 
characteristics) 

•  fabrication  and  manufacturing  requirements  (for  both 
the  original  equipment  manufacturer  and  field  support) 

•  the  verification  criteria  used  to  ensure  requirements 
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have  been  achieved 

•  conditions  of  use  (environments)  and  operating/usage 
scenarios,  modes  and  states  for  operations,  support, 
training,  manufacturing,  disposal,  and  verifications 
throughout  the  life  of  the  product 

•  rationale  for  decisions  and  characteristics 
(requirements,  requirement  allocations;  design  choices) 

Properties  (attributes)  of  products  or  services  to  be  acquired 
or  developed. 

Detailed  instructions  for  the  setup,  execution,  and  evaluation 
of  results  for  a  given  test. 

(See  “requirements  traceability.”) 

An  evaluation  of  alternatives  based  on  criteria  and 
systematic  analysis,  to  select  the  best  alternative  for 
attaining  determined  objectives. 

In  the  Organizational  Training  process  area,  see  the 
definition  of  “training”  in  the  introductory  notes. 

See  Chapter  2  for  an  explanation  of  how  “typical  work 
product”  is  used  in  the  CMMI  Product  Suite. 


Testing  of  individual  hardware  or  software  units  or  groups  of 
related  units.  (See  “acceptance  testing.”) 


See  Chapter  3  for  an  explanation  of  how  “validation”  is  used 
in  the  CMMI  Product  Suite. 

See  Chapter  3  for  an  explanation  of  how  “verification”  is 
used  in  the  CMMI  Product  Suite. 

A  common  feature  of  CMMI  model  process  areas  with  a 
staged  representation  that  groups  the  generic  practices 
related  to  review  by  higher  level  management,  and  objective 
evaluation  of  conformance  to  process  descriptions, 
procedures,  and  standards. 

The  establishment  and  maintenance  of  baselines  and  the 
identification  of  changes  to  baselines  that  make  it  possible 
to  return  to  the  previous  baseline. 
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weakness 

work  breakdown 
structure 

work  product 

work  product  and 
task  attributes 


As  used  in  CMMI  appraisal  materials,  the  ineffective,  or  lack 
of,  implementation  of  one  or  more  CMMI  model  practices. 

An  arrangement  of  work  elements  and  their  relationship  to 
each  other  and  to  the  end  product. 

See  Chapter  3  for  an  explanation  of  how  “work  product”  is 
used  in  the  CMMI  Product  Suite. 

Characteristics  of  products,  services,  and  project  tasks  used 
to  help  in  estimating  project  work.  These  characteristics 
include  items  such  as  size,  complexity,  weight,  form,  fit,  or 
function.  They  are  typically  used  as  one  input  to  deriving 
other  project  and  resource  estimates  (e.g.,  effort,  cost, 
schedule). 
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D.  Required  and  Expected  Model  Elements 


Required  and  Expected  Model  Elements 
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PROCESS  MANAGEMENT 


Process  Management 
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ORGANIZATIONAL  PROCESS  FOCUS 

Process  Management 


The  purpose  of  Organizational  Process  Focus  is  to  plan  and  implement 
organizational  process  improvement  based  on  a  thorough 
understanding  of  the  current  strengths  and  weaknesses  of  the 
organization’s  processes  and  process  assets.  [PA152] 


Practices  by  Goal: 


SG  1  Determine  Process-Improvement  Opportunities 

Strengths,  weaknesses,  and  improvement  opportunities  for  the  organization's 
processes  are  identified  periodically  and  as  needed.  [pais2.igioii 


SP  1.1-1  Establish  Organizational  Process  Needs 

Establish  and  maintain  the  description  of  the  process  needs  and 
objectives  for  the  organization,  [paiszigwi.spwii 


SP  1.2-1  Appraise  the  Organization’s  Processes 

Appraise  the  processes  of  the  organization  periodically  and  as 
needed  to  maintain  an  understanding  of  their  strengths  and 
weaknesses,  [pais2.igioi.spi 021 


SP  1.3-1  Identify  the  Organization's  Process  Improvements 

Identify  improvements  to  the  organization's  processes  and 
process  assets.  [pais2.igioi.spio3] 


SG  2  Plan  and  Implement  Process-Improvement  Activities 


Improvements  are  planned  and  implemented,  organizational  process  assets 
are  deployed,  and  process-related  experiences  are  incorporated  into  the 
organizational  process  assets.  [PA152.1G102] 


SP  2.1-1  Establish  Process  Action  Plans 

Establish  and  maintain  process  action  plans  to  address 
improvements  to  the  organization's  processes  and  process 

assets.  [PA152.IG102.SP1 01] 
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SP  2.2-1  Implement  Process  Action  Plans 

Implement  process  action  plans  across  the  organization. 

[PA152.IG102.SP1 02] 

SP  2.3-1  Deploy  Organizational  Process  Assets 

Deploy  organizational  process  assets  across  the  organization. 

[PA152.IG102.SP103] 

SP  2.4-1  Incorporate  Process-Related  Experiences  into  the  Organizational 
Process  Assets 

Incorporate  process-related  work  products,  measures,  and 
improvement  information  derived  from  planning  and  performing 
the  process  into  the  organizational  process  assets,  [pais2.igio2.spw4] 
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ORGANIZATIONAL  PROCESS  DEFINITION _ 

Process  Management 

The  purpose  of  Organizational  Process  Definition  is  to  establish  and 
maintain  a  usable  set  of  organizational  process  assets.  [PA153] 

Practices  by  Goal: 

SG  1  Establish  Organizational  Process  Assets 

_ A  set  of  organizational  process  assets  is  established  and  maintained.  [pais3.igioi]  | 

SP  1.1-1  Establish  Standard  Processes 

Establish  and  maintain  the  organization's  set  of  standard 
processes.  [pai53.igioi.spioi] 


SP  1.2-1  Establish  Life-Cycle  Model  Descriptions 

Establish  and  maintain  descriptions  of  the  life-cycle  models 
approved  for  use  in  the  organization,  [pais3.igwi.spw2] 


SP  1.3-1  Establish  Tailoring  Criteria  and  Guidelines 

Establish  and  maintain  the  tailoring  criteria  and  guidelines  for  the 
organization's  set  of  standard  processes,  [pais3.igwi.spw3] 


SP  1.4-1  Establish  the  Organization’s  Measurement  Repository 

Establish  and  maintain  the  organization’s  measurement 
repository,  [pais3.igioi.spw4] 

SP  1.5-1  Establish  the  Organization’s  Process  Asset  Library 

Establish  and  maintain  the  organization's  process  asset  library. 

[PA1S3.IGW1.SPW5] 
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ORGANIZATIONAL  TRAINING _ 

Process  Management 

The  purpose  of  Organizational  Training  is  to  develop  the  skills  and 
knowledge  of  people  so  they  can  perform  their  roles  effectively  and 
efficiently,  [paissj 

Practices  by  Goal: 

SG  1  Establish  an  Organizational  Training  Capability 

A  training  capability  that  supports  the  organization's  management  and 
technical  roles  is  established  and  maintained,  [paisb.igioi] 


SP  1.1-1  Establish  the  Strategic  Training  Needs 

Establish  and  maintain  the  strategic  training  needs  of  the 
organization,  [pais8.igioi.spwi] 


SP  1.2-1  Determine  Which  Training  Needs  Are  the  Responsibility  of  the 
Organization 

Determine  which  training  needs  are  the  responsibility  of  the 
organization  and  which  will  be  left  to  the  individual  project  or 
support  group,  [pais8.igwi.spw2] 

SP  1.3-1  Establish  an  Organizational  Training  Tactical  Plan 

Establish  and  maintain  an  organizational  training  tactical  plan. 

[PA1S8.IGW1.SPW3] 

SP  1.4-1  Establish  Training  Capability 

Establish  and  maintain  training  capability  to  address 
organizational  training  needs,  [pais8.igwi.spw4] 

SG  2  Provide  Necessary  Training 

Training  necessary  for  individuals  to  perform  their  roles  effectively  is 
provided.  [pais8.igio2] 
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SP  2.1-1  Deliver  Training 

Deliver  the  training  following  the  organizational  training  tactical 

plan.  [PA158.1G102.SP101] 

SP  2.2-1  Establish  Training  Records 

Establish  and  maintain  records  of  the  organizational  training. 

[PA  158.IG102.SP102] 

SP  2.3-1  Assess  Training  Effectiveness 

Assess  the  effectiveness  of  the  organization’s  training  program. 

[PA  158.IG102.SP103] 
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ORGANIZATIONAL  PROCESS  PERFORMANCE _ 

Process  Management 

The  purpose  of  Organizational  Process  Performance  is  to  establish  and 
maintain  a  quantitative  understanding  of  the  performance  of  the 
organization’s  set  of  standard  processes  in  support  of  quality  and 
process-performance  objectives,  and  to  provide  the  process 
performance  data,  baselines,  and  models  to  quantitatively  manage  the 
organization’s  projects.  [pai64] 

Practices  by  Goal: 

SG  1  Establish  Performance  Baselines  and  Models 

Baselines  and  models  that  characterize  the  expected  process  performance  of 
the  organization's  set  of  standard  processes  are  established  and  maintained. 

[PA164.IG101] 


SP  1.1-1  Select  Processes 

Select  the  processes  or  process  elements  in  the  organization's  set 
of  standard  processes  that  are  to  be  included  in  the  organization's 
process  performance  analyses.  [paw4.igioi.spwi] 


SP  1.2-1  Establish  Process  Performance  Measures 

Establish  and  maintain  definitions  of  the  measures  that  are  to  be 
included  in  the  organization's  process  performance  analyses. 

[PA1 64.IG101  .SP1 02] 


SP  1.3-1  Establish  Quality  and  Process-Performance  Objectives 

Establish  and  maintain  quantitative  objectives  for  quality  and 
process  performance  for  the  organization,  [pai64.igwi.spw3] 


SP  1.4-1  Establish  Process  Performance  Baselines 

Establish  and  maintain  the  organization's  process  performance 
baselines,  [pai64.igwi.spw4] 


Process  Management,  Organizational  Process  Performance 


575 


CMMI-SW,  vl.1 
Continuous  Representation 


Establish  Process  Performance  Models 


SP  1.5-1 

Establish  and  maintain  the  process  performance  models  for  the 
organization's  set  of  standard  processes,  [pai64.igioi.spws] 
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ORGANIZATIONAL  INNOVATION  AND  DEPLOYMENT 

Process  Management 


The  purpose  of  Organizational  Innovation  and  Deployment  is  to  select 
and  deploy  incremental  and  innovative  improvements  that  measurably 
improve  the  organization's  processes  and  technologies.  The 
improvements  support  the  organization's  quality  and  process- 
performance  objectives  as  derived  from  the  organization's  business 
objectives.  [PAiei] 


Practices  by  Goal: 


SG  1  Select  Improvements 

Process  and  technology  improvements  that  contribute  to  meeting  quality  and 
process-performance  objectives  are  selected,  [pawi.igioii 


SP  1.1-1  Collect  and  Analyze  Improvement  Proposals 

Collect  and  analyze  process-  and  technology-improvement 
proposals.  [PA161.IG101.SPW1] 


SP  1.2-1  Identify  and  Analyze  Innovations 

Identify  and  analyze  innovative  improvements  that  could  increase 
the  organization’s  quality  and  process  performance,  [pai6i.igioi.spw2] 


SP  1.3-1  Pilot  Improvements 

Pilot  process  and  technology  improvements  to  select  which  ones 
to  implement,  [pai6i.igwi.spw3] 


SP  1.4-1  Select  Improvements  for  Deployment 

Select  process-  and  technology-improvement  proposals  for 
deployment  across  the  organization,  [pai6i.igwi.spw4] 


SG  2  Deploy  Improvements 


Measurable  improvements  to  the  organization's  processes  and  technologies 
are  continually  and  systematically  deployed.  [pawi.igio2] 
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SP  2.1-1  Plan  the  Deployment 

Establish  and  maintain  the  plans  for  deploying  the  selected 
process  and  technology  improvements,  [pm6i.igio2.spwi] 


SP  2.2-1  Manage  the  Deployment 

Manage  the  deployment  of  the  selected  process  and  technology 
improvements,  [pai6i.igw2.spi 02] 


SP  2.3-1  Measure  Improvement  Effects 

Measure  the  effects  of  the  deployed  process  and  technology 
improvements,  ipai6i.igw2.spw3] 


578 


Process  Management,  Organizational  Innovation  and  Deployment 


CMMI-SW,  vl.1 
Continuous  Representation 


PROJECT  MANAGEMENT 


Project  Management 


579 


CMMI-SW,  vl.1 
Continuous  Representation 


PROJECT  PLANNING 

Project  Management 


The  purpose  of  Project  Planning  is  to  establish  and  maintain  plans  that 
define  project  activities.  [pai63] 


Practices  by  Goal: 


SG  1  Establish  Estimates 


Estimates  of  project  planning  parameters  are  established  and  maintained. 

[PA163.IG101] 


SP  1.1-1  Estimate  the  Scope  of  the  Project 

Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate 
the  scope  of  the  project.  [pai63.igwi.spwi] 


SP  1.2-1  Establish  Estimates  of  Work  Product  and  Task  Attributes 

Establish  and  maintain  estimates  of  the  attributes  of  the  work 
products  and  tasks,  [pai63.igwi.spi 021 


SP  1.3-1  Define  Project  Life  Cycle 

Define  the  project  life-cycle  phases  upon  which  to  scope  the 
planning  effort,  [pai63.igwi.spw3] 


SP  1.4-1  Determine  Estimates  of  Effort  and  Cost 

Estimate  the  project  effort  and  cost  for  the  work  products  and 
tasks  based  on  estimation  rationale,  [pai63.igwi.spw4] 


SG  2  Develop  a  Project  Plan 


A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the 

project.  [PA163.IG102] 
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SP  2.1-1  Establish  the  Budget  and  Schedule 

Establish  and  maintain  the  project’s  budget  and  schedule. 

[PA163.IG102.SP101] 


SP  2.2-1  Identify  Project  Risks 

Identify  and  analyze  project  risks.  [pai63.igio2.spio3] 


SP  2.3-1  Plan  for  Data  Management 

Plan  for  the  management  of  project  data,  [pai63.igio2.spw2] 


SP  2.4-1  Plan  for  Project  Resources 

Plan  for  necessary  resources  to  perform  the  project,  [pai63.igio2.spw4] 


SP  2.5-1  Plan  for  Needed  Knowledge  and  Skills 

Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

[PA163.IGW2.SP10  5] 


SP  2.6-1  Plan  Stakeholder  Involvement 

Plan  the  involvement  of  identified  stakeholders,  [pai63.igw2.spw6] 


SP  2.7-1  Establish  the  Project  Plan 

Establish  and  maintain  the  overall  project  plan  content. 

[PA163.IG102.SP107] 


SG  3  Obtain  Commitment  to  the  Plan 


Commitments  to  the  project  plan  are  established  and  maintained.  [paw3.igio3] 


SP  3.1-1  Review  Plans  that  Affect  the  Project 

Review  all  plans  that  affect  the  project  to  understand  project 
commitments,  [pai63.igw3.spw3] 
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SP  3.2-1  Reconcile  Work  and  Resource  Levels 

Reconcile  the  project  plan  to  reflect  available  and  estimated 
resources.  [pai63.igio3.spwi] 


SP  3.3-1  Obtain  Plan  Commitment 

Obtain  commitment  from  relevant  stakeholders  responsible  for 
performing  and  supporting  plan  execution,  [pai63.igio3.spw2] 
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PROJECT  MONITORING  AND  CONTROL _ 

Project  Management 

The  purpose  of  Project  Monitoring  and  Control  is  to  provide  an 
understanding  of  the  project’s  progress  so  that  appropriate  corrective 
actions  can  be  taken  when  the  project’s  performance  deviates 
significantly  from  the  plan,  [pai 62] 

Practices  by  Goal: 

SG  1  Monitor  Project  Against  Plan 

Actual  performance  and  progress  of  the  project  are  monitored  against  the 
project  plan.  [paw2.igioi] 

SP  1.1-1  Monitor  Project  Planning  Parameters 

Monitor  the  actual  values  of  the  project  planning  parameters 
against  the  project  plan,  [pai62.igioi.spwi] 

SP  1.2-1  Monitor  Commitments 

Monitor  commitments  against  those  identified  in  the  project  plan. 

[PA162.IG101  .SP102] 

SP  1.3-1  Monitor  Project  Risks 

Monitor  risks  against  those  identified  in  the  project  plan. 

[PA162.IG101  .SP103] 

SP  1.4-1  Monitor  Data  Management 

Monitor  the  management  of  project  data  against  the  project  plan. 

[PA162.IG101.SP106] 

SP  1.5-1  Monitor  Stakeholder  Involvement 

Monitor  stakeholder  involvement  against  the  project  plan. 

[PA162.IG101  .SP107] 
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SP  1.6-1  Conduct  Progress  Reviews 

Periodically  review  the  project's  progress,  performance,  and 

issues.  [PA162.IG101.SP104] 


SP  1.7-1  Conduct  Milestone  Reviews 

Review  the  accomplishments  and  results  of  the  project  at  selected 
project  milestones,  [pm62.igioi.spw5] 


SG  2  Manage  Corrective  Action  to  Closure 


Corrective  actions  are  managed  to  closure  when  the  project's  performance  or 
results  deviate  significantly  from  the  plan.  [paw2.igio2] 


SP  2.1-1  Analyze  Issues 

Collect  and  analyze  the  issues  and  determine  the  corrective 
actions  necessary  to  address  the  issues,  [pai62.igio2.spwi] 


SP  2.2-1  Take  Corrective  Action 

Take  corrective  action  on  identified  issues,  [pm62.igio2.spw2] 


SP  2.3-1  Manage  Corrective  Action 

Manage  corrective  actions  to  closure,  [pm62.igw2.spw3] 
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SUPPLIER  AGREEMENT  MANAGEMENT 

Project  Management 


The  purpose  of  Supplier  Agreement  Management  is  to  manage  the 
acquisition  of  products  from  suppliers  for  which  there  exists  a  formal 
agreement.  [PAieej 


Practices  by  Goal: 


SG  1  Establish  Supplier  Agreements 


Agreements  with  the  suppliers  are  established  and  maintained,  [pawb.igioi] 


SP  1.1-1  Determine  Acquisition  Type 

Determine  the  type  of  acquisition  for  each  product  or  product 
component  to  be  acquired,  [pai66.igioi.spwi] 


SP  1.2-1  Select  Suppliers 

Select  suppliers  based  on  an  evaluation  of  their  ability  to  meet  the 
specified  requirements  and  established  criteria,  [pai66.igwi.spw2] 


SP  1.3-1  Establish  Supplier  Agreements 

Establish  and  maintain  formal  agreements  with  the  supplier. 

[PA166.IG101.SPW3] 


SG  2  Satisfy  Supplier  Agreements 


Agreements  with  the  suppliers  are  satisfied  by  both  the  project  and  the 
supplier.  [pai66.igio2] 


SP  2.1-1  Review  COTS  Products 

Review  candidate  COTS  products  to  ensure  they  satisfy  the 
specified  requirements  that  are  covered  under  a  supplier 
agreement,  [pai66.igw2.spwi] 
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SP  2.2-1  Execute  the  Supplier  Agreement 

Perform  activities  with  the  supplier  as  specified  in  the  supplier 
agreement.  [pai66.igio2.spio2] 


SP  2.3-1  Accept  the  Acquired  Product 

Ensure  that  the  supplier  agreement  is  satisfied  before  accepting 
the  acquired  product,  ipai66.igio2.spw3] 

SP  2.4-1  Transition  Products 

Transition  the  acquired  products  from  the  supplier  to  the  project. 

[PA166.IG102.SP104] 
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INTEGRATED  PROJECT  MANAGEMENT 

Project  Management 


The  purpose  of  Integrated  Project  Management  is  to  establish  and 
manage  the  project  and  the  involvement  of  the  relevant  stakeholders 
according  to  an  integrated  and  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes.  [pai67] 


Practices  by  Goal: 


SG  1  Use  the  Project’s  Defined  Process 

The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the 
organization's  set  of  standard  processes.  [paw7.igioi] 


SP  1.1-1  Establish  the  Project’s  Defined  Process 

Establish  and  maintain  the  project's  defined  process,  [pai67.igioi.spwi] 


SP  1.2-1  Use  Organizational  Process  Assets  for  Planning  Project  Activities 

Use  the  organizational  process  assets  and  measurement 
repository  for  estimating  and  planning  the  project’s  activities. 

[PA1 67.IG1 01  .SP102] 


SP  1.3-1  Integrate  Plans 

Integrate  the  project  plan  and  the  other  plans  that  affect  the 
project  to  describe  the  project’s  defined  process,  [pai67.igioi.spw3] 


SP  1.4-1  Manage  the  Project  Using  the  Integrated  Plans 

Manage  the  project  using  the  project  plan,  the  other  plans  that 
affect  the  project,  and  the  project’s  defined  process,  [pai67.igwi.spw4] 


SP  1.5-1  Contribute  to  the  Organizational  Process  Assets 

Contribute  work  products,  measures,  and  documented 
experiences  to  the  organizational  process  assets,  [pai67.igwi.spws] 
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SG  2  Coordinate  and  Collaborate  with  Relevant  Stakeholders 


Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  is 
conducted.  [pai67.igio2] 


SP  2.1-1  Manage  Stakeholder  Involvement 

Manage  the  involvement  of  the  relevant  stakeholders  in  the 
project.  [pai67.igio2.spioi] 


SP  2.2-1  Manage  Dependencies 

Participate  with  relevant  stakeholders  to  identify,  negotiate,  and 
track  critical  dependencies,  [pai67.igio2.spw2] 


SP  2.3-1  Resolve  Coordination  Issues 

Resolve  issues  with  relevant  stakeholders,  [pai67.igio2.spw3] 
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RISK  MANAGEMENT 

Project  Management 


The  purpose  of  Risk  Management  is  to  identify  potential  problems 
before  they  occur,  so  that  risk-handling  activities  may  be  planned  and 
invoked  as  needed  across  the  life  of  the  product  or  project  to  mitigate 
adverse  impacts  on  achieving  objectives.  [pai48] 


Practices  by  Goal: 


SG  1  Prepare  for  Risk  Management 


Preparation  for  risk  management  is  conducted,  [paus.igiov 


SP  1.1-1  Determine  Risk  Sources  and  Categories 

Determine  risk  sources  and  categories,  [paus.igioi.spwi] 


SP  1.2-1  Define  Risk  Parameters 

Define  the  parameters  used  to  analyze  and  categorize  risks,  and 
the  parameters  used  to  control  the  risk  management  effort. 

[PA148.IG101  .SP102] 


SP  1.3-1  Establish  a  Risk  Management  Strategy 

Establish  and  maintain  the  strategy  to  be  used  for  risk 
management.  [pam8.igioi.spio3] 


SG  2  Identify  and  Analyze  Risks 


Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

[PA148.IG102] 


SP  2.1-1  Identify  Risks 

Identify  and  document  the  risks.  [pau8.igio2.spioi] 
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SP  2.2-1  Evaluate,  Categorize,  and  Prioritize  Risks 

Evaluate  and  categorize  each  identified  risk  using  the  defined  risk 
categories  and  parameters,  and  determine  its  relative  priority. 

[PA1 48.IG102.SP1 02] 

SG  3  Mitigate  Risks 

Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse 
impacts  on  achieving  objectives.  [paub.igio3] 


SP  3.1-1  Develop  Risk  Mitigation  Plans 

Develop  a  risk  mitigation  plan  for  the  most  important  risks  to  the 
project,  as  defined  by  the  risk  management  strategy.  [pai48.igio3.spioi] 


SP  3.2-1  Implement  Risk  Mitigation  Plans 

Monitor  the  status  of  each  risk  periodically  and  implement  the  risk 
mitigation  plan  as  appropriate,  [pau8.igio3.spw2] 
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QUANTITATIVE  PROJECT  MANAGEMENT _ 

Project  Management 

The  purpose  of  the  Quantitative  Project  Management  process  area  is  to 
quantitatively  manage  the  project’s  defined  process  to  achieve  the 
project’s  established  quality  and  process-performance  objectives,  [paibs] 

Practices  by  Goal: 

SG  1  Quantitatively  Manage  the  Project 

The  project  is  quantitatively  managed  using  quality  and  process-performance 
objectives,  [paws.igioi] 


SP  1.1-1  Establish  the  Project’s  Objectives 

Establish  and  maintain  the  project’s  quality  and  process' 
performance  objectives,  [pai65.igwi.spwi] 


SP  1.2-1  Compose  the  Defined  Process 

Select  the  subprocesses  that  compose  the  project’s  defined 
process  based  on  historical  stability  and  capability  data. 

[PA165.IG101  .SP102] 


SP  1.3-1  Select  the  Subprocesses  that  Will  Be  Statistically  Managed 

Select  the  subprocesses  of  the  project's  defined  process  that  will 
be  statistically  managed,  [pai65.igioi.spw3] 


SP  1.4-1  Manage  Project  Performance 

Monitor  the  project  to  determine  whether  the  project’s  objectives 
for  quality  and  process  performance  will  be  satisfied,  and  identify 
corrective  action  as  appropriate,  [pai65.igwi.spw4] 

SG  2  Statistically  Manage  Subprocess  Performance 

The  performance  of  selected  subprocesses  within  the  project's  defined 
process  is  statistically  managed.  [paws.igio2] 
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SP  2.1-1  Select  Measures  and  Analytic  Techniques 

Select  the  measures  and  analytic  techniques  to  be  used  in 
statistically  managing  the  selected  subprocesses,  ipm65.igio2.spwi] 


SP  2.2-1  Apply  Statistical  Methods  to  Understand  Variation 

Establish  and  maintain  an  understanding  of  the  variation  of  the 
selected  subprocesses  using  the  selected  measures  and  analytic 
techniques,  [pai6s.igio2.spw2] 


SP  2.3-1  Monitor  Performance  of  the  Selected  Subprocesses 

Monitor  the  performance  of  the  selected  subprocesses  to 
determine  their  capability  to  satisfy  their  quality  and  process- 
performance  objectives,  and  identify  corrective  action  as 
necessary,  [pai65.igio2.spw3] 


SP  2.4-1  Record  Statistical  Management  Data 

Record  statistical  and  quality  management  data  in  the 
organization’s  measurement  repository,  [paw5.igio2.spw4] 
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ENGINEERING 


Engineering 
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REQUIREMENTS  MANAGEMENT _ 

Engineering 

The  purpose  of  Requirements  Management  is  to  manage  the 
requirements  of  the  project's  products  and  product  components  and  to 
identify  inconsistencies  between  those  requirements  and  the  project's 
plans  and  work  products.  [pai46] 

Practices  by  Goal: 

SG  1  Manage  Requirements 

Requirements  are  managed  and  inconsistencies  with  project  plans  and  work 
products  are  identified,  [paub.igwi] 


SP  1.1-1  Obtain  an  Understanding  of  Requirements 

Develop  an  understanding  with  the  requirements  providers  on  the 
meaning  of  the  requirements,  ipaub.igioi.spioi] 


SP  1.2-2  Obtain  Commitment  to  Requirements 

Obtain  commitment  to  the  requirements  from  the  project 
participants,  [pau6.igioi.spw2] 


SP  1.3-1  Manage  Requirements  Changes 

Manage  changes  to  the  requirements  as  they  evolve  during  the 

project.  [PA146.IG101.SP103] 


SP  1.4-2  Maintain  Bidirectional  Traceability  of  Requirements 

Maintain  bidirectional  traceability  among  the  requirements  and  the 
project  plans  and  work  products,  [pau6.igwi.spw4] 


SP  1.5-1  Identify  Inconsistencies  between  Project  Work  and  Requirements 

Identify  inconsistencies  between  the  project  plans  and  work 
products  and  the  requirements,  [pau6.igioi.spw5] 
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REQUIREMENTS  DEVELOPMENT 

Engineering 


The  purpose  of  Requirements  Development  is  to  produce  and  analyze 
customer,  product,  and  product-component  requirements.  [pais7] 


Practices  by  Goal: 


SG  1  Develop  Customer  Requirements 

Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and 
translated  into  customer  requirements.  [pais7.igioi] 


SP  1.1-1  Collect  Stakeholder  Needs 

Identify  and  collect  stakeholder  needs,  expectations,  constraints, 
and  interfaces  for  all  phases  of  the  product  life  cycle,  [pais7.igioi.spwi] 


In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Elicit  Needs  specific  practice. 


SP  1.1-2  Elicit  Needs 

Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces 
for  all  phases  of  the  product  life  cycle,  [pais7.igioi.spw2] 

In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Collect 
Stakeholder  Needs  specific  practice. 


SP  1.2-1  Develop  the  Customer  Requirements 

Transform  stakeholder  needs,  expectations,  constraints,  and 
interfaces  into  customer  requirements,  [pai57.igwi.spw3] 


SG  2  Develop  Product  Requirements 


Customer  requirements  are  refined  and  elaborated  to  develop  product  and 
product-component  requirements.  [pais7.igio3] 
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SP  2.1-1  Establish  Product  and  Product-Component  Requirements 

Establish  and  maintain  product  and  product-component 
requirements,  which  are  based  on  the  customer  requirements. 

[PA157.IG103.SP101] 


SP  2.2-1  Allocate  Product-Component  Requirements 

Allocate  the  requirements  for  each  product  component. 

[PA1 57.IG1 03.SP1 02] 


SP  2.3-1  Identify  Interface  Requirements 

Identify  interface  requirements,  [pai57.igw3.spw3] 


SG  3  Analyze  and  Validate  Requirements 


The  requirements  are  analyzed  and  validated,  and  a  definition  of  required 
functionality  is  developed.  [pais7.igw2 / 


SP  3.1-1  Establish  Operational  Concepts  and  Scenarios 

Establish  and  maintain  operational  concepts  and  associated 
scenarios,  [pais7.igw2.spwi] 


SP  3.2-1  Establish  a  Definition  of  Required  Functionality 

Establish  and  maintain  a  definition  of  required  functionality. 

[PA157.IG102.SP1 02] 


SP  3.3-1  Analyze  Requirements 

Analyze  requirements  to  ensure  that  they  are  necessary  and 

Sufficient.  [PAi57.lGW2.SPW3] 


SP  3.4-3  Analyze  Requirements  to  Achieve  Balance 

Analyze  requirements  to  balance  stakeholder  needs  and 
constraints,  [pais7.igio2.spw4] 


SP  3.5-1  Validate  Requirements 

Validate  requirements  to  ensure  the  resulting  product  will  perform 
appropriately  in  its  intended-use  environment,  [pais7.igw2.spws] 
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In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Validate  Requirements  with  Comprehensive 
Methods  specific  practice. 


SP  3.5-2  Validate  Requirements  with  Comprehensive  Methods 

Validate  requirements  to  ensure  the  resulting  product  will  perform 
as  intended  in  the  user's  environment  using  multiple  techniques 
as  appropriate,  i pai57.igio2.spiobi 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Validate 
Requirements  specific  practice. 
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TECHNICAL  SOLUTION 

Engineering 


The  purpose  of  Technical  Solution  is  to  design,  develop,  and  implement 
solutions  to  requirements.  Solutions,  designs,  and  implementations 
encompass  products,  product  components,  and  product-related  life- 
cycle  processes  either  singly  or  in  combinations  as  appropriate,  [paibo] 


Practices  by  Goal: 


SG  1  Select  Product-Component  Solutions 


Product  or  product-component  solutions  are  selected  from  alternative 
solutions.  [PAI60.1G101] 


SP  1.1-1  Develop  Alternative  Solutions  and  Selection  Criteria 

Develop  alternative  solutions  and  selection  criteria,  [pawo.igioi.spwi] 

In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria  specific  practice. 

SP  1.1-2  Develop  Detailed  Alternative  Solutions  and  Selection  Criteria 
Develop  detailed  alternative  solutions  and  selection  criteria. 

[PA160.IG101.SP102] 


In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Develop 
Alternative  Solutions  and  Selection  Criteria  specific  practice. 


SP  1.2-2  Evolve  Operational  Concepts  and  Scenarios 

Evolve  the  operational  concept,  scenarios,  and  environments  to 
describe  the  conditions,  operating  modes,  and  operating  states 
specific  to  each  product  component,  [pai6o.igwi.spw3] 


SP  1.3-1  Select  Product -Component  Solutions 

Select  the  product-component  solutions  that  best  satisfy  the 
criteria  established,  [pai6o.igwi.spw4] 
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SG  2  Develop  the  Design 


Product  or  product-component  designs  are  developed,  [pawo.igiov 

SP  2.1-1 

Design  the  Product  or  Product  Component 

SP  2.2-3 

Develop  a  design  for  the  product  or  product  component. 

[PA  1 60.  IG102.  SP101] 

Establish  a  Technical  Data  Package 

SP  2.3-1 

Establish  and  maintain  a  technical  data  package,  ipai6o.igio2.spw3]  j 

Establish  Interface  Descriptions 

SP  2.3-3 

Establish  and  maintain  the  solution  for  product-component 
interfaces.  [pai6o.igio2.spio4] 

In  the  staged  representation,  this  specific  practice  is  only  included  as  informative 
material  and  appears  after  the  Design  Interfaces  Using  Criteria  specific  practice. 

Design  Interfaces  Using  Criteria 

SP  2.4-3 

Design  comprehensive  product-component  interfaces  in  terms  of 
established  and  maintained  criteria,  ipai6o.igio2.spws] 

In  the  staged  representation,  this  specific  practice  takes  the  place  of  the  Establish 
Interface  Descriptions  specific  practice. 

Perform  Make,  Buy,  or  Reuse  Analyses 

SG  3  Implement 

Evaluate  whether  the  product  components  should  be  developed, 
purchased,  or  reused  based  on  established  criteria,  [pai6o.igw2.spw6] 

the  Product  Design 

Product  components,  and  associated  support  documentation,  are 
implemented  from  their  designs.  [pai6o.igio3i 

SP  3.1-1 

Implement  the  Design 

Implement  the  designs  of  the  product  components,  [pai6o.igw3.spwi]  j 
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SP  3.2-1  Develop  Product  Support  Documentation 

Develop  and  maintain  the  end-use  documentation,  ipaibo.igio3.spi 021 
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PRODUCT  INTEGRATION 


Engineering 

The  purpose  of  Product  Integration  is  to  assemble  the  product  from  the 
product  components,  ensure  that  the  product,  as  integrated,  functions 
properly,  and  deliver  the  product,  [paw] 

Practices  by  Goal: 

SG  1 

Prepare  for  Product  Integration 

Preparation  for  product  integration  is  conducted.  [pau7.igioii 

SP  1.1-1 

Determine  Integration  Sequence 

Determine  the  product-component  integration  sequence. 

[PA147.IG101.SP101] 

SP  1.2-2 

Establish  the  Product  Integration  Environment 

Establish  and  maintain  the  environment  needed  to  support  the 
integration  of  the  product  components,  [pau7.igioi.spw2] 

SP  1.3-3 

Establish  Product  Integration  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  integration  of 
the  product  components,  [pau7.igioi.spw3] 

SG2 

Ensure  Interface  Compatibility 

The  product-component  interfaces,  both  internal  and  external,  are  compatible. 

[PA147.IG102] 

SP  2.1-1 

Review  Interface  Descriptions  for  Completeness 

Review  interface  descriptions  for  coverage  and  completeness. 

[PA1 47.IG102.SP1 01] 
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SP  2.2-1  Manage  Interfaces 

Manage  internal  and  external  interface  definitions,  designs,  and 
changes  for  products  and  product  components,  [pau7.igio2.spi 02] 


SG  3  Assemble  Product  Components  and  Deliver  the  Product 


Verified  product  components  are  assembled  and  the  integrated,  verified,  and 
validated  product  is  delivered.  ipau7.igio3] 


SP  3.1-1  Confirm  Readiness  of  Product  Components  for  Integration 

Confirm,  prior  to  assembly,  that  each  product  component  required 
to  assemble  the  product  has  been  properly  identified,  functions 
according  to  its  description,  and  that  the  product-component 
interfaces  comply  with  the  interface  descriptions.  ipau7.igio3.spioi] 


SP  3.2-1  Assemble  Product  Components 

Assemble  product  components  according  to  the  product 
integration  sequence  and  available  procedures.  [pau7.igio3.spw2] 


SP  3.3-1  Evaluate  Assembled  Product  Components 

Evaluate  assembled  product  components  for  interface 
compatibility.  [pau7.igio3.spio3] 


SP  3.4-1  Package  and  Deliver  the  Product  or  Product  Component 

Package  the  assembled  product  or  product  component  and  deliver 
it  to  the  appropriate  customer.  [pau7.igio3.spw4] 
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VERIFICATION 


Engineering 

The  purpose  of  Verification  is  to  ensure  that  selected  work  products 
meet  their  specified  requirements,  [paisoi 

Practices  by  Goal: 

SG  1 

Prepare  for  Verification 

Preparation  for  verification  is  conducted,  [paiso.igioi] 

SP  1.1-1 

Select  Work  Products  for  Verification 

Select  the  work  products  to  be  verified  and  the  verification 
methods  that  will  be  used  for  each,  [paiso.igioi.spwi] 

SP  1.2-2 

Establish  the  Verification  Environment 

Establish  and  maintain  the  environment  needed  to  support 
verification,  [paiso.igwi.spw2] 

SP  1.3-3 

Establish  Verification  Procedures  and  Criteria 

Establish  and  maintain  verification  procedures  and  criteria  for  the 
selected  work  products,  [paiso.igwi.spw3] 

SG2 

Perform 

Peer  Reviews 

Peer  reviews  are  performed  on  selected  work  products,  [paiso.igioi 

SP  2.1-1  Prepare  for  Peer  Reviews 

Prepare  for  peer  reviews  of  selected  work  products,  [paiso.igio2.spwi] 


SP  2.2-1  Conduct  Peer  Reviews 

Conduct  peer  reviews  on  selected  work  products  and  identify 
issues  resulting  from  the  peer  review,  ipaiso.igio2.spi 02] 
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SP  2.3-2  Analyze  Peer  Review  Data 

Analyze  data  about  preparation,  conduct,  and  results  of  the  peer 
reviews.  [paiso.igio2.spio3] 


SG  3  Verify  Selected  Work  Products 


Selected  work  products  are  verified  against  their  specified  requirements. 

[PA150.IG103] 


SP  3.1-1  Perform  Verification 

Perform  verification  on  the  selected  work  products,  [pm5o.igio3.spwi] 


SP  3.2-2  Analyze  Verification  Results  and  Identify  Corrective  Action 

Analyze  the  results  of  all  verification  activities  and  identify 
corrective  action,  [pai5o.igw3.spw2] 
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VALIDATION 


Engineering 

The  purpose  of  Validation  is  to  demonstrate  that  a  product  or  product 
component  fulfills  its  intended  use  when  placed  in  its  intended 
environment.  [pam9] 

Practices  by  Goal: 

SG  1 

Prepare  for  Validation 

Preparation  for  validation  is  conducted.  ipau9.igioi] 

SP  1.1-1 

Select  Products  for  Validation 

Select  products  and  product  components  to  be  validated  and  the 
validation  methods  that  will  be  used  for  each,  [paus.igioi.spioi] 

SP  1.2-2 

Establish  the  Validation  Environment 

Establish  and  maintain  the  environment  needed  to  support 
validation,  [pau9.igioi.spw2] 

SP  1.3-3 

Establish  Validation  Procedures  and  Criteria 

Establish  and  maintain  procedures  and  criteria  for  validation. 

[PA  1 49.  IG  101.SP1 03] 

SG2 

Validate  Product  or  Product  Components 

The  product  or  product  components  are  validated  to  ensure  that  they  are 
suitable  for  use  in  their  intended  operating  environment.  [pau9.igio2] 

SP  2.1-1 

Perform  Validation 

Perform  validation  on  the  selected  products  and  product 
components.  [pai49.igio2.spioij 
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SP  2.2-1  Analyze  Validation  Results 

Analyze  the  results  of  the  validation  activities  and  identify  issues. 

[PA1 49.IG102.SP1 02] 
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SUPPORT 


Support 
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CONFIGURATION  MANAGEMENT 


Support 

The  purpose  of  Configuration  Management  is  to  establish  and  maintain 
the  integrity  of  work  products  using  configuration  identification, 
configuration  control,  configuration  status  accounting,  and  configuration 
audits.  [PA159] 

Practices  by  Goal: 

SG  1 

Establish  Baselines 

Baselines  of  identified  work  products  are  established,  [pais9.igwii 

SP  1.1-1 

Identify  Configuration  Items 

Identify  the  configuration  items,  components,  and  related  work 
products  that  will  be  placed  under  configuration  management. 

[PA159.IG101.SP101] 

SP  1.2-1 

Establish  a  Configuration  Management  System 

Establish  and  maintain  a  configuration  management  and  change 
management  system  for  controlling  work  products,  [pais9.igwi.spw2] 

SP  1.3-1 

Create  or  Release  Baselines 

Create  or  release  baselines  for  internal  use  and  for  delivery  to  the 

CUStOmer.  [PA1S9.IGW1.SP103] 

SG  2 

Track  and 

Control  Changes 

Changes  to  the  work  products  under  configuration  management  are  tracked 
and  controlled.  [pais9.igio2] 

SP  2.1-1 

Track  Change  Requests 

Track  change  requests  for  the  configuration  items,  [pai59.igw2.spwi] 
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SP  2.2-1  Control  Configuration  Items 

Control  changes  to  the  configuration  items.  [PAi59.iGi02.spw2] 


SG  3  Establish  Integrity 


Integrity  of  baselines  is  established  and  maintained.  [pais9.igio3] 


SP  3.1-1  Establish  Configuration  Management  Records 

Establish  and  maintain  records  describing  configuration  items. 

[PA159.IG103.SP101] 


SP  3.2-1  Perform  Configuration  Audits 

Perform  configuration  audits  to  maintain  integrity  of  the 
configuration  baselines,  [pai59.igio3.spw2] 
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PROCESS  AND  PRODUCT  QUALITY  ASSURANCE 


Support 

The  purpose  of  Process  and  Product  Quality  Assurance  is  to  provide 
staff  and  management  with  objective  insight  into  processes  and 
associated  work  products,  [paus] 

Practices  by  Goal: 

SG  1 

Objectively  Evaluate  Processes  and  Work  Products 

Adherence  of  the  performed  process  and  associated  work  products  and 
services  to  applicable  process  descriptions,  standards,  and  procedures  is 
objectively  evaluated,  [paus.igioi] 

SP  1.1-1 

Objectively  Evaluate  Processes 

Objectively  evaluate  the  designated  performed  processes  against 
the  applicable  process  descriptions,  standards,  and  procedures. 

[PA145.IG101.SP101] 

SP  1.2-1 

Objectively  Evaluate  Work  Products  and  Services 

Objectively  evaluate  the  designated  work  products  and  services 
against  the  applicable  process  descriptions,  standards,  and 
procedures.  [paus.igioi.spio2] 

SG2 

Provide  Objective  Insight 

Noncompliance  issues  are  objectively  tracked  and  communicated,  and 
resolution  is  ensured,  i paus.igio 2; 

SP  2.1-1 

Communicate  and  Ensure  Resolution  of  Noncompliance  Issues 

Communicate  quality  issues  and  ensure  resolution  of 
noncompliance  issues  with  the  staff  and  managers.  [paus.igio2.spioi] 

SP  2.2-1 

Establish  Records 

Establish  and  maintain  records  of  the  quality  assurance  activities. 

[PA1 45.IG102.SP1 02] 
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MEASUREMENT  AND  ANALYSIS 

Support 


The  purpose  of  Measurement  and  Analysis  is  to  develop  and  sustain  a 
measurement  capability  that  is  used  to  support  management 
information  needs.  [pai54] 


Practices  by  Goal: 


SG  1  Align  Measurement  and  Analysis  Activities 


Measurement  objectives  and  activities  are  aligned  with  identified  information 
needs  and  objectives,  [paim.igioij 


SP  1.1-1  Establish  Measurement  Objectives 

Establish  and  maintain  measurement  objectives  that  are  derived 
from  identified  information  needs  and  objectives,  [pais4.igwi.spwi] 


SP  1.2-1  Specify  Measures 

Specify  measures  to  address  the  measurement  objectives. 

[PA154.IG101.SP102] 


SP  1.3-1  Specify  Data  Collection  and  Storage  Procedures 

Specify  how  measurement  data  will  be  obtained  and  stored. 

[PA154.IGW1.SPW3] 


SP  1.4-1  Specify  Analysis  Procedures 

Specify  how  measurement  data  will  be  analyzed  and  reported. 

[PA154.IG101.SPW4] 


SG  2  Provide  Measurement  Results 


Measurement  results  that  address  identified  information  needs  and  objectives 
are  provided.  [PA154.1G102] 
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SP  2.1-1  Collect  Measurement  Data 

Obtain  specified  measurement  data,  [pai54.igw2.spwi] 


SP  2.2-1  Analyze  Measurement  Data 

Analyze  and  interpret  measurement  data,  [pm54.igw2.spw2] 


SP  2.3-1  Store  Data  and  Results 

Manage  and  store  measurement  data,  measurement 
specifications,  and  analysis  results,  [pm54.igw2.spw3] 


SP  2.4-1  Communicate  Results 

Report  results  of  measurement  and  analysis  activities  to  all 
relevant  stakeholders,  [pm54.igw2.spw4] 
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DECISION  ANALYSIS  AND  RESOLUTION 

Support 


The  purpose  of  Decision  Analysis  and  Resolution  is  to  analyze  possible 
decisions  using  a  formal  evaluation  process  that  evaluates  identified 
alternatives  against  established  criteria,  [pai*] 


Practices  by  Goal: 


SG  1  Evaluate  Alternatives 


Decisions  are  based  on  an  evaluation  of  alternatives  using  established 
criteria.  [pais6.igioi] 


SP  1.1-1  Establish  Guidelines  for  Decision  Analysis 

Establish  and  maintain  guidelines  to  determine  which  issues  are 
subject  to  a  formal  evaluation  process,  [paisb.igioi.spioi] 


SP  1.2-1  Establish  Evaluation  Criteria 

Establish  and  maintain  the  criteria  for  evaluating  alternatives,  and 
the  relative  ranking  of  these  criteria,  [pais6.igioi.spw3] 


SP  1.3-1  Identify  Alternative  Solutions 

Identify  alternative  solutions  to  address  issues,  [pais6.igioi.spw4] 


SP  1.4-1  Select  Evaluation  Methods 

Select  the  evaluation  methods,  i pais6.igwi.spw2 y 


SP  1.5-1  Evaluate  Alternatives 

Evaluate  alternative  solutions  using  the  established  criteria  and 
methods,  [pais6.igioi.spws] 


SP  1.6-1  Select  Solutions 

Select  solutions  from  the  alternatives  based  on  the  evaluation 
criteria,  [pais6.igwi.spw6] 
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CAUSAL  ANALYSIS  AND  RESOLUTION 


Support 

The  purpose  of  Causal  Analysis  and  Resolution  is  to  identify  causes  of 
defects  and  other  problems  and  take  action  to  prevent  them  from 
occurring  in  the  future,  [paissj 

Practices  by  Goal: 

SG  1 

Determine  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  determined. 

[PA155.IG101] 

SP  1.1-1 

Select  Defect  Data  for  Analysis 

Select  the  defects  and  other  problems  for  analysis,  [paiss.igioi.spioi]  ] 

SP  1.2-1 

Analyze  Causes 

Perform  causal  analysis  of  selected  defects  and  other  problems 
and  propose  actions  to  address  them.  [pais5.igioi.spio2i 

SG2 

Address  Causes  of  Defects 

Root  causes  of  defects  and  other  problems  are  systematically  addressed  to 
prevent  their  future  occurrence.  [paiss.igio2i 

SP  2.1-1 

Implement  the  Action  Proposals 

Implement  the  selected  action  proposals  that  were  developed  in 
causal  analysis.  [paiss.igio2.spioi] 

SP  2.2-1 

Evaluate  the  Effect  of  Changes 

Evaluate  the  effect  of  changes  on  process  performance. 

[PA155.IG102.SP1 02] 
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SP  2.3-1  Record  Data 

Record  causal  analysis  and  resolution  data  for  use  across  the 
project  and  organization.  [paiss.igio2.spio3] 
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GENERIC  GOALS  AND  GENERIC  PRACTICES 


GG  1  Achieve  Specific  Goals 


The  process  supports  and  enables  achievement  of  the  specific  goals  of  the 
process  area  by  transforming  identifiable  input  work  products  to  produce 
identifiable  output  work  products. 


GP  1.1  Perform  Base  Practices 

Perform  the  base  practices  of  the  process  area  to  develop  work 
products  and  provide  services  to  achieve  the  specific  goals  of  the 
process  area.  [gpio2] 


GG  2  Institutionalize  a  Managed  Process 


The  process  is  institutionalized  as  a  managed  process. 


GP  2.1  Establish  an  Organizational  Policy 

Establish  and  maintain  an  organizational  policy  for  planning  and 
performing  the  process.  [gpio3i 


GP  2.2  Plan  the  Process 

Establish  and  maintain  the  plan  for  performing  the  process,  [gpimi 


GP  2.3  Provide  Resources 

Provide  adequate  resources  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process,  igpiosi 


GP  2.4  Assign  Responsibility 

Assign  responsibility  and  authority  for  performing  the  process, 
developing  the  work  products,  and  providing  the  services  of  the 
process,  [gpiobi 
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GP  2.5  Train  People 

Train  the  people  performing  or  supporting  the  process  as  needed. 

[GP107] 


GP  2.6  Manage  Configurations 

Place  designated  work  products  of  the  process  under  appropriate 
levels  of  configuration  management,  [gpiosi 


GP  2.7  Identify  and  Involve  Relevant  Stakeholders 

Identify  and  involve  the  relevant  stakeholders  as  planned.  [gpi24] 


GP  2.8  Monitor  and  Control  the  Process 

Monitor  and  control  the  process  against  the  plan  for  performing 
the  process  and  take  appropriate  corrective  action,  [gpuoi 


GP  2.9  Objectively  Evaluate  Adherence 

Objectively  evaluate  adherence  of  the  process  against  its  process 
description,  standards,  and  procedures,  and  address 
noncompliance,  [GP1131 


GP  2.10  Review  Status  with  Higher  Level  Management 

Review  the  activities,  status,  and  results  of  the  process  with 
higher  level  management  and  resolve  issues.  igph2j 


GG  3  Institutionalize  a  Defined  Process 


The  process  is  institutionalized  as  a  defined  process. 


GP  3.1  Establish  a  Defined  Process 

Establish  and  maintain  the  description  of  a  defined  process,  [gpiuj 


GP  3.2  Collect  Improvement  Information 

Collect  work  products,  measures,  measurement  results,  and 
improvement  information  derived  from  planning  and  performing 
the  process  to  support  the  future  use  and  improvement  of  the 
organization’s  processes  and  process  assets.  [gph7] 
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GG  4  Institutionalize  a  Quantitatively  Managed  Process 

The  process  is  institutionalized  as  a  quantitatively  managed  process. 


GP  4.1  Establish  Quantitative  Objectives  for  the  Process 

Establish  and  maintain  quantitative  objectives  for  the  process  that 
address  quality  and  process  performance  based  on  customer 
needs  and  business  objectives,  t gpus ; 


GP  4.2  Stabilize  Subprocess  Performance 

Stabilize  the  performance  of  one  or  more  subprocesses  to 
determine  the  ability  of  the  process  to  achieve  the  established 
quantitative  quality  and  process-performance  objectives,  [gpusj 

GG  5  Institutionalize  an  Optimizing  Process 

The  process  is  institutionalized  as  an  optimizing  process. 


GP  5.1  Ensure  Continuous  Process  Improvement 

Ensure  continuous  improvement  of  the  process  in  fulfilling  the 
relevant  business  objectives  of  the  organization.  igpi2S] 


GP  5.2  Correct  Root  Causes  of  Problems 

Identify  and  correct  the  root  causes  of  defects  and  other  problems 
in  the  process.  [GP1211 
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F.  Equivalent  Staging 


Equivalent  staging  is  a  target  staging  that  is  equivalent  to  the  maturity 
levels  of  the  staged  representation,  [fmus.tioi] 

Table  2  shows  the  target  profiles  that  must  be  achieved  when  using  the 
continuous  representation  to  be  equivalent  to  a  maturity  level  when 
using  a  staged  representation.  [fmh5.tio2] 

The  columns  of  the  figure  have  the  following  meanings:  [fmh5.tio3] 

•  “Name”  is  the  full  name  of  the  process  area. 

•  “Abbr”  is  the  acronym  corresponding  to  the  “Name.” 

•  “ML”  is  the  maturity  level  assignment  of  the  process  area  in  the 
staged  representation. 

•  “CL1 “CL2,”  “CL3,”  “CL4,”  “CL5”  are  headings  for  the  columns 
assigned  to  capability  levels  in  the  continuous  representation. 

The  shaded  areas  in  the  capability  level  columns  indicate  target  profiles 
that  are  equivalent  to  maturity  levels  in  the  staged  representation. 

[FM1 15.T104] 

•  To  achieve  target  profile  2  (and  thereby  be  equivalent  to  maturity 
level  2),  the  process  areas  to  the  left  of  target  profile  2  must  have 
satisfied  capability  levels  1  and  2. 

•  To  achieve  target  profile  3  (and  thereby  be  equivalent  to  maturity 
level  3),  the  process  areas  to  the  left  of  target  profiles  2  and  3  must 
have  satisfied  capability  levels  1,  2,  and  3. 

•  To  achieve  target  profile  4  (and  thereby  be  equivalent  to  maturity 
level  4),  the  process  areas  to  the  left  of  target  profiles  2,  3  and  4 
must  have  satisfied  capability  levels  1,  2,  and  3. 

•  To  achieve  target  profile  5  (and  thereby  be  equivalent  to  maturity 
level  5),  all  of  the  process  areas  must  have  satisfied  capability 
levels  1 , 2,  and  3. 
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Name 

Abbr 

ML 

CL1  CL2 

CL3 

CL4  CL5 

Requirements  Management 

REQM 

2 

Measurement  and  Analysis 

MA 

2 

Project  Monitoring  and  Control 

PMC 

2 

Target 

Project  Planning 

PP 

2 

Profile 

Process  and  Product  Quality 
Assurance 

PPQA 

2 

2 

Supplier  Agreement  Management 

SAM 

2 

Configuration  Management 

CM 

2 

Decision  Analysis  and  Resolution 

DAR 

3 

Product  Integration 

PI 

3 

Requirements  Development 

RD 

3 

Technical  Solution 

TS 

3 

Validation 

VAL 

3 

Target 

Verification 

VER 

3 

- 

Profile  J 

Organizational  Process  Definition 

OPD 

3 

Organizational  Process  Focus 

OPF 

3 

Integrated  Project  Management 

IPM 

3 

Risk  Management 

RSKM 

3 

Organizational  Training 

OT 

3 

Organizational  Process 

Performance 

OPP 

4 

Quantitative  Project  Management 

QPM 

4 

Organizational  Innovation  and 
Deployment 

OID 

5 

Causal  Analysis  and  Resolution 

CAR 

5 

Table  2:  Target  Profiles  and  Equivalent  Staging  [fmhs.tiosi 

A  general  rule  for  equivalent  staging:  [fmh5.th2] 

•  To  achieve  maturity  level  2,  all  process  areas  assigned  to  maturity 
level  2  must  achieve  capability  level  2  or  above. 

•  To  achieve  maturity  level  3,  all  process  areas  assigned  to  maturity 
levels  2  and  3  must  achieve  capability  level  3  or  above. 

•  To  achieve  maturity  level  4,  all  process  areas  assigned  to  maturity 
levels  2,  3,  and  4  must  achieve  capability  level  3  or  above. 

•  To  achieve  maturity  level  5,  all  process  areas  must  achieve 
capability  level  3  or  above. 
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The  above  rule  and  table  for  equivalent  staging  is  complete,  but  a 
question  that  is  often  asked  is  “why  don’t  target  profiles  4  and  5  extend 
into  the  CL4  and  CL5  columns?”  The  maturity  level  4  process  areas 
describe  a  selection  of  the  subprocesses  to  be  stabilized  based,  in  part, 
on  the  quality  and  process-performance  objectives  of  the  organization 
and  projects.  Not  every  process  area  will  be  addressed  in  the  selection 
and  the  model  does  not  presume  in  advance  which  process  areas  might 
be  addressed  in  the  selection.  The  achievement  of  capability  level  4  for 
process  areas  cannot  be  predetermined  because  the  choices  will  be 
dependent  upon  the  selections  made  by  the  organization  in  its 
implementation  of  the  maturity  level  4  process  areas.  Thus,  the  table 
above  does  not  show  target  profile  4  extending  into  the  CL4  column 
although  some  process  areas  will  have  achieved  capability  level  4.  The 
situation  for  maturity  level  5  and  target  profile  5  is  similar.  [fmh5.tio6] 

The  existence  of  equivalent  staging  should  not  discourage  users  of  the 
continuous  representation  from  establishing  target  profiles  that  extend 
above  capability  level  3.  That  target  profile  would  be  determined  in  part 
by  the  selections  made  by  the  organization  as  described  in  the  previous 
paragraph,  [fmus.tw] 
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